[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [vfio-users] passthrough VGA for widespread use?



Rokas,

Gerd is the maker of the patches and I suggested something like this because I use a cheap and dirty program that I wrote to switch monitor inputs via i2c bus over the hdmi cable directly. I have a monitor with two hdmi inputs so I switch between them. He's thinking of adding that later. Currently you need to do something like autohotkey or manually switch the monitor over.

Jon

On 1 Mar 2016 10:16, "Rokas Kupstys" <rokups zoho com> wrote:
Hey Jonathan,
Is there any way for host to manage keyboard/mouse switching with your patches? What i mean is i use KVM switch to toggle between host/VM cards. Be nice of keyboard/mouse could follow active display. Now i dont know how to capture this display switch event but linux would not be linux if that were not possible. With that said be nice if we could run some script on host and toggle switching of keyboard/mouse to/from VM. Think that could be possible?

On 2016.03.01 12:08, Jonathan Scruggs wrote:

I have no lag. The patches make the keyboard/mouse directly available on the guest as a real device. This way I have one keyboard and mouse for both host and guest. The technical bit is that the input buffers are forwarded to the guest. Synergy is nice but there is lag with that. These patches are real time! I play the latest AAA games too. I haven't noticed anything. It doesn't hurt to try. I can post my libvirt config if need be. I'll need to get the git address of the latest version.

Jon

On Feb 29, 2016 10:23 PM, "thibaut noah" <thibaut noah gmail com> wrote:
What about input lag with the patch?
The point of using passthrough on usb controller is to get direct input for games
On Mon, 29 Feb 2016 at 21:37, Jonathan Scruggs <j scruggs gmail com> wrote:

Those patches are supposed to be added to mainline at some point. They are stable and work great!

On 29 Feb 2016 20:33, "Will Marler" <will wmarler com> wrote:
Oh, good point, that is an option too (although I personally I stay away from patching)

On Mon, Feb 29, 2016 at 1:29 PM, Jonathan Scruggs <j scruggs gmail com> wrote:

For keyboard and mouse, grab the patches in this mailing list that pass through your host keyboard and mouse as a standard PS/2 device. You press both CTRL keys to switch between host and guest. Works very well. You also have full BIOS control of the guest and Windows UAC pop-ups can be clicked on where as synergy gets blocked by those prompts.

On 29 Feb 2016 17:44, "Will Marler" <will wmarler com> wrote:
a) I've never had Host or Guest crash problems. I have had problems with programs crashing in the guest with nebulous errors (or no errors) that seem related to graphics. They are reproducible, but not reliably so, and I have never tried to verify if those crashes exist on baremetal. 

d) Synergy works great for simple functions (when you need keyboard & 2-button mouse). In my experience it is not a good solution for games, as some games will interpret the mouse inputs weirldy (small physical mouse movements resulting in HUGE cursor movements), and the full spectrum of buttons doesn't get translated through.

On Sat, Feb 27, 2016 at 1:02 AM, Rokas Kupstys <rokups zoho com> wrote:
b) VM even if qemu runs as root is still more secure than running software in your own session. More things need to be broken to get to the host with virtualisation in place.

c) virt-manager can do almost all whats needed. Might need to edit xmls by hand to switch it to uefi though. Or to add few flags not supported by virt-manager, but as far as device assignment goes virt-manager does handle it.


On 2016.02.26 23:09, Muted Bytes wrote:

From my experience:

I would consider usage stable for an average user, but I'm not sure about set-up for a non-technical user.

a) In my specific case, I am forced to use Windows because a lot of simulation and computational tools are only available on that platform, but I chose to operate in a VM rather than baremetal. As a result, I have both memory and cpu intensive simulations running in the guest for days at a time, and idle for weeks/months (shutdown only for host maintenance etc). Have never had guest or host crash or freeze (even through guest restarts).

b) I cannot provide comment, I am also running qemu as root. I intend to look at how to move away from root execution of qemu but haven't yet (virtsh makes this easier/possible from what I've read but haven't looked in detail).

c) I am also still using qemu from command-line so cannot comment, but I have been watching progression of virtsh and virt-manager. I think it already is at/getting to that point.

d) I am using synergy to switch between screens/share kb and mouse with guest. In my case, if the mouse is left on guest side, the guest can lock but synergy prevents the host from locking. The mouse needs to be on host side for me. Also, my guest and host lock independently, so I'm not sure if there is a way to synchronize this.
Copy/paste generally works well with text in both directions, however there seem to be some issues with more recent versions of synergy upstream that makes the server portion to hang/crash that seems to be related to the copy buffer (though I'm not 100% sure this is the cause). I haven't encountered this in a while, so it has been intermittent in my case. One good thing about synergy is that you can set it up so that scroll lock key will lock the mouse/kb to one side (guest or host) if you plan to work or game in that environment for a long session, and don't want the mouse to accidentally switch context on the screen edge/boundary. This also makes fullscreen and FPS games playable in the guest without the mouse going nuts from losing relative position information.

On Feb 25, 2016 22:59, "Daniel Pocock" <daniel pocock pro> wrote:

Is a passthrough VGA configuration currently considered stable and
secure for widespread use, for example, where non-technical users can
work productively with applications running this way in an office
environment?

Some specific things come to mind:

a) crashes: I've seen crashes mentioned in a few discussions, but are
there many people running it for days and weeks at a time without
crashes?  Are such issues specific to particular hardware and can they
be avoided by using hardware that is preferred/more heavily tested by
the developers?

b) security: in my testing so far, I just run the qemu command as root.
 To what extent can the use of root privileges be avoided?  I realize a
VM is never 100% secure compared to a normal user session.

c) control: some of the blogs and wikis mention that tools like
virt-manager and virt-install don't fully cope with passthrough VGA
configuration, is that still up to date?  Can the user start and manage
the VM using some GUI from their X desktop on their host display?

d) interaction between VM and host desktop: when the user locks the host
display (screensaver), can this also lock the VM's passthrough display,
or the user will always need to lock both?  How well does something like
Synergy work across the displays, especially for things like cut-and-paste?

_______________________________________________
vfio-users mailing list
vfio-users redhat com
https://www.redhat.com/mailman/listinfo/vfio-users


_______________________________________________
vfio-users mailing list
vfio-users redhat com
https://www.redhat.com/mailman/listinfo/vfio-users


_______________________________________________
vfio-users mailing list
vfio-users redhat com
https://www.redhat.com/mailman/listinfo/vfio-users



_______________________________________________
vfio-users mailing list
vfio-users redhat com
https://www.redhat.com/mailman/listinfo/vfio-users


_______________________________________________
vfio-users mailing list
vfio-users redhat com
https://www.redhat.com/mailman/listinfo/vfio-users


_______________________________________________
vfio-users mailing list
vfio-users redhat com
https://www.redhat.com/mailman/listinfo/vfio-users


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]