[vfio-users] passthrough VGA for widespread use?
Rokas Kupstys
rokups at zoho.com
Tue Mar 1 10:15:54 UTC 2016
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 at gmail.com
> <mailto:thibaut.noah at 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 at gmail.com <mailto:j.scruggs at 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 at wmarler.com
> <mailto:will at 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 at gmail.com <mailto:j.scruggs at 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 at wmarler.com
> <mailto:will at 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 at zoho.com <mailto:rokups at 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 at pocock.pro
>> <mailto:daniel at 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 at redhat.com
>> <mailto:vfio-users at redhat.com>
>> https://www.redhat.com/mailman/listinfo/vfio-users
>>
>>
>>
>> _______________________________________________
>> vfio-users mailing list
>> vfio-users at redhat.com
>> <mailto:vfio-users at redhat.com>
>> https://www.redhat.com/mailman/listinfo/vfio-users
>
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> <mailto:vfio-users at redhat.com>
> https://www.redhat.com/mailman/listinfo/vfio-users
>
>
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com <mailto:vfio-users at redhat.com>
> https://www.redhat.com/mailman/listinfo/vfio-users
>
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com <mailto:vfio-users at redhat.com>
> https://www.redhat.com/mailman/listinfo/vfio-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160301/b7df4662/attachment.htm>
More information about the vfio-users
mailing list