[vfio-users] passthrough VGA for widespread use?

Mon Feb 29 20:37:12 UTC 2016

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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160229/26128eb6/attachment.htm>