Xen users - Apr 2007 - 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?

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?

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@lists.xensource.com
http://lists.xensource.com/xen-users

> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com 
> [mailto:xen-users-bounces@lists.xensource.com] 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@lists.xensource.com
http://lists.xensource.com/xen-users

> 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].
Just to chime in here: definitely do this if your guest supports it (I think 
most Linux guests don''t, but Windows does).  It makes interaction with
the
guest much more smooth: the mouse pointer in the guest lines up exactly with 
where you move the mouse in the host *and* it lets you have "grabless"
operation (move the mouse freely in and out of the VM''s window without
using
any funny key combos).

If you have a Windows version that supports remote desktop, you might find it 
better to connect to it using the Linux rdesktop client.  If you use 
http://www.cendio.com/seamlessrdp/ seamless RDP you can even have it 
integrate with your Linux window manager (each Windows app has a separate 
Window in dom0).
> > 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.
Exactly what I was going to say :-)

Also, you could investigate using Nomachine X to talk to the domUs (it can 
also share printing, sound, files etc in an easy way - if you can get it to 
work.  I''ve used the FreeNX server but getting it to work was
difficult, and
I couldn''t make the advanced features behave - that was a while ago,
though)
but you probably won''t find many advantages over just using X11 over
SSH in
the local case.

X forwarding over SSH has the additional benefit that it''ll integrate
with
your local window manager.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

Thanks for the suggestions about settng usbdevice = "tablet''. 
It''s a vast
improvement.

Not only is the response better, and the transition to and from the the
Windows'' window much easier, but it also solved another highly anoying
problem I had, where the mouse would sometimes refuse to traverse beyond a
certain point within the window.

My interactive response is now about on par with how I remember it when
running windows on native hardware.  Still occasionally slugish, but then it
is Windows!

Thanks!

Derek.


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

Although I don''t think it is available from the Home edition of
Windows XP, Remote Desktop is the solution that feels the snappier in
my opinion.

2007/4/18, Derek <xen@sherlockmail.com>:
> Thanks for the suggestions about settng usbdevice = "tablet''.
It''s a vast
> improvement.
>
> Not only is the response better, and the transition to and from the the
> Windows'' window much easier, but it also solved another highly
anoying
> problem I had, where the mouse would sometimes refuse to traverse beyond a
> certain point within the window.
>
> My interactive response is now about on par with how I remember it when
> running windows on native hardware.  Still occasionally slugish, but then
it
> is Windows!
>
> Thanks!
>
> Derek.
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Petersson, Mats wrote:
> 
>  
> 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. 
> 
> 
> 
Hi,

I know this is a very "ancient post". But I''m wondering... 
How does Xen
knows whom the interrupt belongs to. And where is that function in the Xen
source that does that?

I''ve been trying to source that answer for quite some time already. 

Advice needed urgently. 

Thanks in advance!

Regards,
Tan
-- 
View this message in context:
http://www.nabble.com/Interacting-with-graphical-domU%27s-on-workstation-tp10036536p23627849.html
Sent from the Xen - User mailing list archive at Nabble.com.


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