RE: [Xen-users] Interacting with graphical domU's on workstation

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Derek
> Sent: 17 April 2007 15:33
> To: xen ml
> Subject: [Xen-users] Interacting with graphical domU's on workstation
> 
> Hi,
>  
> My current workstation setup:
>  
> VT capable dual core CPU (core 2 duo). 
> HP pavilion d4600y.
> Dom0 = linux, running X server
> DomU = WinXP home edition, displaying via SDL (whatever that 
> is, I don't really understand) over the Dom0 X server.
> (plus other domUs, all currently HVM but will add Para later.)
>  
> The system is used as a workstation, i.e. plenty of 
> display/mouse/keyboard interaction, so would like to make the 
> interactive user inerface as smooth and seamless as possible. 
>  The main windows applications are Quicken, Web browsing, MS 
> Office.  I don't do video games or anything that demainding 
> on display performance.  The display hardware is pretty basic 
> -- whatever chip comes built in on low-end HP pavilion PCs.  
> Some sort of Nvidia if I recall right? 
>  
> I've noticed that the winXP domU can have somewhat jerky 
> mouse response.  Don't know to what extent it's Windows 
> itsself responding badly, or an artifact of the virtual 
> environment I'm running it in.  My question:  Is there a 
> better setup I should use?  For example, should I run some 
> sort of framebuffer library instead of X on the Dom0 ?  Is 
> there a version of SDL that runs under such a library?  Would 
> that help?  It seems to me that would reduce the number of 
> layers that user interaction passes through en route to the 
> DomU.  Any other suggestions for making the windowsXP domain 
> respond as much as possible like it was running on native hardware? 

This is caused by two things in general:
1. Virtual machine doesn't respond the same as "bare-metal" when it
comes to interrupts - the interrupt latency is much longer in the
average case. On bare-metal, an interrupt will be pretty much taken
"immediately", whilst in a virtual machine, it may well take until the
next "sceduling cycle" before the guest runs. Scheduling in Xen is done
in 10ms increments, which in comparison to bare-metal. [This is not
always the case, but that's not really helpful]. 

2. Virtual machine is getting the keyboard and moust movements via QEMU.
To get from Windows to QEMU, there are several steps, each of which adds
to the total latency too. When the guest recieves the interrupt from
"mouse has moved", it takes the interrupt some number of cycles later,
reads the IO-port of the virtual mouse/keyboard controller (or virtual
USB-device if that's what you're using as mouse-interface) which causes
a VMEXIT. The VMEXIT then causes a IO-request to QEMU (which includes a
"event-channel" to Dom0 and Dom0 waking QEMU). QEMU then decodes the IO
access and does whatever the keyboard/mouse controller would have done
in the real hardware, e.g. deliver the position data and mouse-button
status). Then the guest is awakened again. 

Just to give you an idea, a move of the mouse from one corner of the
screen to another can be as much as 300 or more mouse interrupts. 

Since mouse-movements are "accellerated" based on the timing of the
movement (that is, if you move the mouse quickly across the screen, it
moves further than if you move it slowly), the timing of the interaction
with the mouse becomes important.

Hint: if you aren't already using the setting of "usbdevice=tablet" in
your guest, I would recommend this, as it improves the reliability of
the mouse by quite a bit [because the "tablet" is an "absolute"
positioning pointing device, whilst a mouse is relative positioning -
the latter is much harder to emulate when you get absolute coordinates
back from the SDL/VNC-code]. 

Unfortunately, it's very hard to do anything much to improve this by any
noticable amount.

>  
> In case it complicates matters:  I do also run interactive 
> graphical stuff on the linux domain.  Currently, it runs on 
> dom0, but I'd like to move it to a (probably paravirualized) 
> Linux domU eventually.  I don't know what the 
> display/mouse/keyboard strategy for that should be either.  
> Just run X on domU and export the displays?  Use SDL?  Use VNC? 

I would run DomU as a "remote machine", e.g. use "ssh -X domu", and use
either Dom0 or some completely different machine as display server. This
works really well with almost any Linux applications. 

--
Mats

>  
> Anyway, I'd like to hear people's opinions on the best way to 
> configure a workstation for smooth mouse/keyboard/display 
> interaction with windows and Linux DomUs.
>  
> Thanks,
> Derek.
> 



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users