[vfio-users] passthrough VGA for widespread use?

Tue Mar 1 10:27:44 UTC 2016

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 at 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 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
>>>
>>
>
> _______________________________________________
> 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/dbf6614f/attachment.htm>