kvm supports gpu passthrough with Nvidia GRID, Quadro, and Telsa K-series. The guest will own the gpu exclusively, so it will need to be hooked up to a separate monitor.

As a note: this probably means that we don't have anything to display inside boxes for the running vm, since it displays to the monitor connected to the gpu.

Note that the nvidia gpus mentioned in comment 2 all require the proprietary nvidia driver for this to work.

In terms of UI, two things will be needed:

- a way to assign the gpu in the box properties

- some idea for what to show in boxes if the vm is using an external display

So the use case for this is no-slowdown for gaming or 3D modeling/animation?

Just to keep everyone in the loop. I now have a working test environment for this. I got the hardware needed and have gotten this to work on virt-manager using system libvirt. Here are the issues/problems I see:

1. Currently its not possible to do this with session libvirt (which is what Boxes focuses on for various good reasons). Getting this to work reliably with session libvirt will involve some major/massive changes in libvirt architecture, according to libvirt devs.

2. The mouse is shared between host and secondary display and hence restricted to the boundaries of host display (actually more like boundaries of VM's virtual display window but its the same thing if you put that in fullscreen). This is less of an issue if both displays are same resolution of course but in my case the secondary display is a 42" TV. However even with both displays the same size, I doubt users would like it that we require them to have the VM's virtual display running in fullscreen on their primary monitor whenever they need to use the VM.

3. To get it working, you gotta do quite a few things outside of virt-manager as admin first: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-device-GPU.html

4. Only a signle VM at a time can use the GPU and part of the setup above is to remove the host driver so it can't be used by host either.

5. I also experienced some hangs of VM but I'm guessing thats a guest driver issue.
--

So I'd suggest a long term and short term plan but with some parts in common between both:

1. Create a script that users need to run as admin that does all the setup (issue#3 above) for them (it won't of course be able to handle the BIOS toggles but it can guide users on what to do when it detects that VT-d isn't available. We'll have to also provide a script that undoes the setup and makes GPU available to host machine. They could actually be the same script with different flags..

2. Teach Boxes how to add the GPU to a VM. This part should actually be trivial, depending on what designers come up with. :) We'll need to keep issue#4 in mind here.

3. Come up and implement a solution for the mouse issue (#2 above) in Boxes. One solution would to require a secondary USB kbd and mouse from users of this use case and then Boxes can simply assign those to VM.

4. For short term
   a. We need to ensure Boxes has no issues using system libvirt as default connection (so that users can create new VMs where they can attach GPU to them). This might be a bit of a work to get right.
   b. Make it easy to make system libvirt the default in Boxes. I don't know if we want a UI for this or not. We currently provide a way to import all VMs from system libvirt through a button in media menu so maybe a choice to switch to system libvirt?

5. For long term, we gotta push libvirt folks to move away from their luxury of focus on system libvirt. Use of system libvirt makes things really easy for them as then they don't have to bother much with permissions on devices etc but its a user's nightmare: All your VMs are shared with other users on the system and you need to elevate permissions (the annoying polkit dialog) to access your VMs. A huge design flaw in libvirt's architecture, IMO.

I think we want to avoid relying on scripts for anything here, I mean the point of Boxes is to free people from doing virtualization on the command line. Maybe Jakub or Allan could figure out where to put this in the UI?

(In reply to Christian Fredrik Kalager Schaller from comment #7)
> I think we want to avoid relying on scripts for anything here, I mean the
> point of Boxes is to free people from doing virtualization on the command
> line. Maybe Jakub or Allan could figure out where to put this in the UI?

Well its not only Boxes alone that aims to do that but GNOME overall. I'm not sure all of that admin-level one-time setup really belongs in Boxes. Having said that, I agree that some sort of UI would be nice for that.

(In reply to Zeeshan Ali (Khattak) from comment #8)
> (In reply to Christian Fredrik Kalager Schaller from comment #7)
> > I think we want to avoid relying on scripts for anything here, I mean the
> > point of Boxes is to free people from doing virtualization on the command
> > line. Maybe Jakub or Allan could figure out where to put this in the UI?
> 
> Well its not only Boxes alone that aims to do that but GNOME overall. I'm
> not sure all of that admin-level one-time setup really belongs in Boxes.
> Having said that, I agree that some sort of UI would be nice for that.

Also we need to keep in mind that this would be a niche use-case, since I don't expect a lot of users having this special hardware setup this use-case requires.

This could pretty nice for dual gfx card machines in general (read most machines with a dedicated graphic card, since both intel and amd are integrating graphics in the cpus latelly), no idea how technically possible would be though.

Zeeshan, ok that it's pretty much a corner case, but requiring an additional mouse and keyboard sound pretty crazy to me, an octopus grade shortcut would be a lot better to switch from host to guest.

(In reply to Lapo Calamandrei from comment #10)
> This could pretty nice for dual gfx card machines in general (read most
> machines with a dedicated graphic card, since both intel and amd are
> integrating graphics in the cpus latelly), no idea how technically possible
> would be though.

It's not possible, at least not in the near future. You need some special graphics cards from Nvidia (comment#1) and they are only available as external models so you'll have to have a desktop machine for them.

> Zeeshan, ok that it's pretty much a corner case, but requiring an additional
> mouse and keyboard sound pretty crazy to me, an octopus grade shortcut would
> be a lot better to switch from host to guest.

That will likely be hard to implement. What I suggested is something that I know will likely work out of the box but I surely need to do more research on this before I can suggest a better solution.

Some comments from me:

1. It is expected and known that only one vm at a time can use the gpu (its only a single gpu, after all...). I think boxes should try to do the right thing in the UI, and a) only offer to pass the gpu to a vm if it is possible, which has a couple of conditions:
  - the vm must be a system one
  - the gpu must not be in use by either the host or another vm

2. I don't think that it is boxes' responsibility to keep the host from touching the gpu. I consider that part of system setup that can be handled outside of boxes. After all, you already had to unscrew your desktop' chassis to put the card in, you can probably handle doing the necessary configuration to make the system ignore it. If we get support for optimus and other multi-gpu scenarios in the display panel, we might eventually try to support this kind of setup there.

3. Why does boxes have to use system libvirt 'as default' ? Can't it talk to both at the same time ?

4. The mouse thing seems tricky. Can't we grab the pointer (as we do for 'normal' displays), and map the dimensions of the boxes window to those of the external monitor, so that the pointer can access the entire monitor ? Of course, resolution will suck if the window is small and the monitor is big...

(In reply to Matthias Clasen from comment #12)
> 
> 3. Why does boxes have to use system libvirt 'as default' ? Can't it talk to
> both at the same time ?

'Default connection' is what Boxes use for creating VMs onto and its what it connects to w/o user defining/adding it. IOW, its the connection that Boxes manages rather than just use. While Boxes can talk to both system and session libvirt, how does it decide where to create the VM? Also, the storage pool will have to be handled differently for system libvirt.

I don't think its a good idea to provide a choice in UI about where to create the VM, either.

> 4. The mouse thing seems tricky. Can't we grab the pointer (as we do for
> 'normal' displays), and map the dimensions of the boxes window to those of
> the external monitor, so that the pointer can access the entire monitor ?

That's what virt-manager does.

> Of
> course, resolution will suck if the window is small and the monitor is big...

Indeed it does and is the case for me.

What we should eventually support here is nvidias vgpu technology:

http://www.nvidia.com/object/virtual-gpus.html

That needs to be supported by kvm and libvirt first, though, and getting the gpu passthrough to work in the meantime is useful.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/43.