> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Sujata Doshi
> Sent: 05 December 2006 15:18
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Question regarding VM_EXIT and VGA
>
> Hi
> I am working on a project using WINDOWS guest on XEN archticture. I
> have a couple of questions.
>
> As I understand when a VM exit occurs due to I/O like say a mouse
> interrupt -- the XEN hypervisor gets a notification and it forwards
> the I/O request to the qemu-dm in Domain-0 via an event channel. Now
> during this VM exit , is the guest OS blocked ?
That depends on what you mean by "blocked". The particular "thread" [in
a wide meaning of the word thread] within the OS is "interrupted", and
the HV (Hypervisor) takes over the execution. This "thread" will not
wake up again until the HV is done with the transaction (until it gets a
reply from qemu in this case).
However, if you have a multiprocessor guest (particularly if there's
more than one physical processor assigned to this guest, but even if
there's only "virtual" mulitple processors, it's entirely possible that
the scheduler decides to run another virtual CPU within the guest-OS),
this processor may perform whatever it likes, including operations that
talk to qemu.
>
> Specifically, what about VGA writes are they blocked too during a VM
> exit ? The following link explains that to speed up performance a
> shared memory area was built between qemu and the hvm guest .
> http://www.intel.com/technology/itj/2006/v10i3/3-xen/5-perform
> ance-tuning-vt-x.htm
Before the shared memory area was included in the Xen distribution, each
and every one of the writes to the VGA memory would cause a Vmexit. If
you had two threads running on different processors, it would cause two
Vmexit to be performed independent of each other (although this is
rarely how it works in real-life applications).
Since the current version of Xen uses a shared memory buffer for all
graphics (essentially, the whole graphics area (frame-buffer) is one
piece of memory shared between qemu and the guest). Updates are
recognised by some sort of "checksum" of the memory - if the checksum
differs, the screen is redrawn [I'm not familiar enough with the code to
say if this is done in small portions or the entire visible area - but
I'm sure of the basic principle of "checksum" and comparing with the old
check-sum to compare the screen with previous version drawn].
Note that the shared memory model doesn't use ANY vmexit to draw on the
screen. The only graphics operations that would cause vmexit in the new
model are places where the graphics driver is doing IOIO operations (as
opposed to writing to the frame-buffer with MMIO) - which is fairly
rare.
>
> But I am unable to understand as to whether is this shared memory area
> is still accessible by the guest vga when a VM exit has taken place
> due to another I/O event like a mouse click?
Simple answer: Yes.
More complex answer: Depends on exactly what was going on at the time of
the mouse-click, and how many processors are available to the guest at
the time. If the guest was running on the only processor that took the
interrupt, then the VMExit happens on that processor - so although the
graphics memory is accessible, the guest is "exited" and the HV runs for
the time needed to process the mouse-click (well, it's obviously no
longer in the HV when it gets to Dom0 and further to qemu-dm - but it's
no longer running in that guest).
If the interrupt is taken by another processor, the guest will still be
able to access the frame-buffer.
If we then assume that the guest is the target of the mouse-click, the
guest will continue to run until the next vmexit (usually a timer-tick
interrupt or halt instruction, but could be MMIO, IOIO, page-fault or
any other type of "exit-reason"). At the end of the VMexit handling, the
code will check for "pending interrupts", and in this instance, it would
be the mouse interrupt. This is then "injected" into the guest by
setting a special word in the VMC[BS], and the virtual processing will
follow the same procedure as if a real interrupt happened to the
processor (including checking if interrupts are enabled etc).
Eventually, this will lead to a IOIO intercept from the mouse driver to
the keyboard/mouse controller (or USB-device if it's a simulated USB
mouse), which is reading the new position of the mouse and/or which
mouse buttons where pressed/released - all of this involves interaction
with QEMU. Eventually the guest will continue to run and send the
message to the guests applications to inform that the mouse moved or a
button was pressed or released.
Whilst during this whole sequence of "figuring out that the mouse moved
or a button changed", the graphics frame-buffer is definitely AVAILABLE,
it's most likely not accessed by the typical drivers involved. Again, if
another processor is available for the guest, that processor could very
well access the graphics memory.
I hope this helps. Please feel free to ask further questions if this
didn't quite explain what you wanted to know.
Finally, it's worth noting that if the graphics setting on the guest is
"stdvga" rather than "cirrus", the guest graphics WILL use Vmexit
(page-fault) for the MMIO to the frame-buffer - so the above applies
only when the graphics is set to "cirrus".
--
Mats
>
> Would appreciate if you could answer my queries.
> Thanks
> Sujata
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home