Ok.. Looks like my comment was taken out of context. Fine.
Attached are some docs I found (sometime ago) from good old "Google" and
by typing Xen.
Some of them are old papers/presentations from Keir & Ian.
Also, what you explained is AMD specific, please post Intel specific
VMCS handling as well to complete the discussion.
-Kaushik
-----Original Message-----
From: Petersson, Mats [mailto:Mats.Petersson@xxxxxxx]
Sent: Thursday, February 15, 2007 2:26 AM
To: Kaushik Barde; aditya shevalkar; xen devel
Subject: RE: [Xen-devel] Communication between guest OS and VMM
I did have a look there, and to me it's not clear exactly what you
(Kaushik) mean is explaining how the Guest in HVM-mode is communicating
with the hypervior. Maybe I'm just too stupid to find it - if you have a
link that explains the below, please post it.
So I'll try to explain it:
There is no DIRECT communication from a Windows guest [1] to the
hypervisor. What happens is that the hypervisor sets up intercept
points, such as writes to certain control registers, events (such as
exceptions and interrupts) and hardware resources and other "stuff" that
the hypervisor wants to monitor in the virtual machine control block
(VMCB) [2]. This happens BEFORE the guest is started. The guest is then
started by the VMRUN [2] instruction, which takes the address of the
VMCB as an argument (implicit, from EAX).
When any of the "intercepts" triggers, a "vmexit" is performed - this
means that the VMRUN instruction "exits" back to the hypervisor. In the
hypervisor, the exit code (aka exit reason) is examined and processed
according to what the trigger was.
Some of the hardware accesses (either a Memory Mapped IO or "IOIO"
instruction [that is the IN/OUT isntructions]) that are performed will
be forwarded to the device model (qemu-dm[3]), using a event-channel
mechanism (see http://wiki.xensource.com/xenwiki/XenEventChannels).
Since these IO events are synchronous in a real processor, the
hypervisor will wait for a "return event" before the guest is allowed to
continue. Qemu-dm runs as a normal user-process in Dom0.
The device model may also issue an message (via event-channel) to
indicate that there's an interrupt from a device in the device-model,
for example due to having read or written a sector to the "hard-disk" in
the simulated IDE controller.
Qemu-dm in turn issues the relevant read/write requests (on
files/disks), network packet requests etc. in Dom0
I hope this explains how it works, even if it may not be exactly what
you asked for. If you have further questions, please feel free to ask.
[1] This holds true unless you have installed "para-virtual drivers" -
these drivers are aware of virtualization, and work based on the same
principle as the drivers in a para-virtual guest with a few small
differences.
[2] I'm using AMD nomenclature. Intel have a very similar concept, but
uses somewhat different names for the data structures, e.g. VMCB is
called VMCS, and instructions, e.g. VMRUN is called VMLAUNCH and
VMRESUME (the first for starting a guest, the second for "continuing"
after a VMEXIT).
[3] Qemu-dm is a modified version of qemu, that contains a selected
software model of PC hardware, such as IDE controller, a selection of
network cards, keyboard/mouse and VGA controller, etc.
--
Mats
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Kaushik Barde
> Sent: 15 February 2007 08:31
> To: aditya shevalkar; xen devel
> Subject: RE: [Xen-devel] Communication between guest OS and VMM
>
> Read stuff from Xen Wiki on XenSource.com.
>
> There's plenty of information available.
>
> -Kaushik
>
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of aditya
> shevalkar
> Sent: Wednesday, February 14, 2007 10:43 PM
> To: xen devel
> Subject: [Xen-devel] Communication between guest OS and VMM
>
> Hi all,
> Please can anybody explain how communication(direct or
> indirect) happens
>
> between xen and guest os(windows) in full virtualization mode.
> Both from VMM to guest and from guest to VMM.
>
> Thanks and regards,
> Aditya.
>
>
>
> __________________________________________________________
> Yahoo! India Answers: Share what you know. Learn something new
> http://in.answers.yahoo.com/
>
> _______________________________________________
> 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
>
>
>
2003-xensosp.pdf
Description: 2003-xensosp.pdf
2006-xen-ols.pdf
Description: 2006-xen-ols.pdf
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home