[vfio-users] passthrough VGA for widespread use?

Tue Mar 1 10:08:28 UTC 2016

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> 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>
> 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> 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>
>>> 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> 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>
>>>>> 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> 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
>>>>>>> https://www.redhat.com/mailman/listinfo/vfio-users
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> vfio-users mailing listvfio-users at redhat.comhttps://www.redhat.com/mailman/listinfo/vfio-users
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> vfio-users mailing list
>>>>>> vfio-users at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/vfio-users
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> vfio-users mailing list
>>>>> vfio-users at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/vfio-users
>>>>>
>>>>>
>>> _______________________________________________
>> vfio-users mailing list
>> 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/fd8b14cc/attachment.htm>