thr3ads.net - Xen devel - [Xen-devel] Communication between guest OS and VMM [Feb 2007]

If this information is useful, please help other people find it:
Share via:

aditya shevalkar

2007-Feb-15 06:42 UTC

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

Kaushik Barde

2007-Feb-15 08:30 UTC

head link

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

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

Petersson, Mats

2007-Feb-15 10:26 UTC

head link

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@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] 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@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] 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@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 


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

Petersson, Mats

2007-Feb-15 13:04 UTC

head link

RE: [Xen-devel] Communication between guest OS and VMM

> -----Original Message-----
> From: aditya shevalkar [mailto:aditya27783@yahoo.co.in] 
> Sent: 15 February 2007 12:53
> To: Petersson, Mats
> Subject: Re: [Xen-devel] Communication between guest OS and VMM
> 
> HI Petresson,
> Thanks for the reply.
> It was a good explaination.
> From the point [1] in your explanation means that it is 
> possible to have para-virtual drivers running in windows 
> which can use para virtual features such as hypercalls etc. 
> without modifeing windows xp OS..
> Does this concept conflicts with the windows lincensing problem.
As far as I''m aware, Windows license doesn''t restrict what
drivers you
run within it [aside from Vista requires that you take steps to make the
driver "signed"]. These drivers are not supplied by Microsoft, so they
are not part of MS license.

Is there any particular clause in MS''s License that you think this
would
conflict with? 

[I must confess I personally haven''t spent any time trying to figure
out
if there are any license restrictions applying to using PV drivers, but
as far as I see it, any device driver that is third party to MS would be
fine in a Windows system - unless the words "para-virtual driver" is
particularly in the license text, this driver is no different from a
USB-device driver from a third party that you install when you buy the
USB-device]. 

Of course, MS will legally (and morally should) not be held responsible
for problems with any third party driver, whether those are for the
para-virtual world or a USB-device... 

--
Mats> 
> Thanks and Regards,
> Aditya.
> [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.
> 
> 
> ----- Original Message ----
> From: "Petersson, Mats" <Mats.Petersson@amd.com>
> To: Kaushik Barde <Kaushik_Barde@Phoenix.com>; aditya 
> shevalkar <aditya27783@yahoo.co.in>; xen devel 
> <xen-devel@lists.xensource.com>
> Sent: Thursday, 15 February, 2007 3:56:22 PM
> 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@lists.xensource.com 
> > [mailto:xen-devel-bounces@lists.xensource.com] 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@lists.xensource.com
> > [mailto:xen-devel-bounces@lists.xensource.com] 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@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> > 
> >
> 
> 
> 		
> __________________________________________________________
> Yahoo! India Answers: Share what you know. Learn something new
> http://in.answers.yahoo.com/
> 
> 
> 


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

Jun Koi

2007-Feb-15 15:12 UTC

head link

Re: [Xen-devel] Communication between guest OS and VMM

On 2/15/07, Petersson, Mats <Mats.Petersson@amd.com>
wrote:> > [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.
Petersson, may you give some more explanation on the differences
between Qemu-dm and Qemu?


Thanks,
Jun

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

Kaushik Barde

2007-Feb-15 20:32 UTC

head link

RE: [Xen-devel] Communication between guest OS and VMM

[This email is either empty or too large to be displayed at this time]

Kaushik Barde

2007-Feb-15 20:55 UTC

head link

RE: [Xen-devel] Communication between guest OS and VMM

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. 

I''d thought question belonged to "Introduction of Xen" and
hence, my
response.

Did not mean to "snub".

Mats, good explanation but what you explained is AMD specific, please
post Intel specific VMCS handling as well to complete the discussion.

-Kaushik 

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Petersson,
Mats
Sent: Thursday, February 15, 2007 5:05 AM
To: aditya shevalkar
Cc: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Communication between guest OS and VMM

 
> -----Original Message-----
> From: aditya shevalkar [mailto:aditya27783@yahoo.co.in] 
> Sent: 15 February 2007 12:53
> To: Petersson, Mats
> Subject: Re: [Xen-devel] Communication between guest OS and VMM
> 
> HI Petresson,
> Thanks for the reply.
> It was a good explaination.
> From the point [1] in your explanation means that it is 
> possible to have para-virtual drivers running in windows 
> which can use para virtual features such as hypercalls etc. 
> without modifeing windows xp OS..
> Does this concept conflicts with the windows lincensing problem.
As far as I''m aware, Windows license doesn''t restrict what
drivers you
run within it [aside from Vista requires that you take steps to make the
driver "signed"]. These drivers are not supplied by Microsoft, so they
are not part of MS license.

Is there any particular clause in MS''s License that you think this
would
conflict with? 

[I must confess I personally haven''t spent any time trying to figure
out
if there are any license restrictions applying to using PV drivers, but
as far as I see it, any device driver that is third party to MS would be
fine in a Windows system - unless the words "para-virtual driver" is
particularly in the license text, this driver is no different from a
USB-device driver from a third party that you install when you buy the
USB-device]. 

Of course, MS will legally (and morally should) not be held responsible
for problems with any third party driver, whether those are for the
para-virtual world or a USB-device... 

--
Mats> 
> Thanks and Regards,
> Aditya.
> [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.
> 
> 
> ----- Original Message ----
> From: "Petersson, Mats" <Mats.Petersson@amd.com>
> To: Kaushik Barde <Kaushik_Barde@Phoenix.com>; aditya 
> shevalkar <aditya27783@yahoo.co.in>; xen devel 
> <xen-devel@lists.xensource.com>
> Sent: Thursday, 15 February, 2007 3:56:22 PM
> 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@lists.xensource.com 
> > [mailto:xen-devel-bounces@lists.xensource.com] 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@lists.xensource.com
> > [mailto:xen-devel-bounces@lists.xensource.com] 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@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> > 
> >
> 
> 
> 		
> __________________________________________________________
> Yahoo! India Answers: Share what you know. Learn something new
> http://in.answers.yahoo.com/
> 
> 
> 


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

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

Keir Fraser

2007-Feb-15 23:56 UTC

head link

Re: [Xen-devel] Communication between guest OS and VMM

On 15/2/07 20:55, "Kaushik Barde" <Kaushik_Barde@Phoenix.com>
wrote:
> Mats, good explanation but what you explained is AMD specific, please
> post Intel specific VMCS handling as well to complete the discussion.
At that level of description Intel VT is almost identical to AMD SVM. The
VMCB is called VMCS and the instructions have different names (and slightly
different usage conventions) but there aren''t any significant
differences
really. Most of the AMD/Intel-specific code for HVM is decoding exits from
the guest back to Xen to work out what happened (the reason codes are all
highly vendor-specific).

 -- Keir



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

Petersson, Mats

2007-Feb-16 10:21 UTC

head link

RE: [Xen-devel] Communication between guest OS and VMM

The second paper (presentation, really) is describing the process of
unmodifed kernel quite nicely. The first one is purely para-virtual, and
has no information useful for understanding how HVM works (it is of
course explaining a lot about virtualization in generic terms and how
para-virtual works). 

As to the differences between Intel/AMD: There are no "REAL"
differences. 
There are minor differences, but the concept and functionality is
identical between the two. Names are different for some the
instructions, the intercept mechanisms have different names and are
organized in slightly different manner. 
Some of the differences:
Intel uses SPECIAL instructions to store/retrieve data from the VMCS,
whilst AMD uses any memory read/write operation to access VMCB (which
means to set a single bit in a VMCB entry requires one OR or BTS
operation, whilst setting the corresponding bit in VMCS requires a
sequece of VMREAD, OR or BTS, VMWRITE). 

There are some differences in handling some control registers - Intel
has a "guest CR0" which is stored separately from the "mahcine
CR0", for
example. So if guest wants to read CR0, it''s read straight out. On AMD,
the read from CR0 is intercepted, and the guest is given the value from
the code in the hypervisor (which has a copy for this purpose:
shadow_cr0). 

MSR handling is somewhat different too. Intel must save/restore certain
MSR''s manually, whilst in the AMD architecture they are managed by the
VMRUN/#VMEXIT mechanism. 

Oh, and the VMCS is indicated to the processor by a VMPTRLD instruction
with the machine physical address, on AMD it''s loaded by EAX containing
the VMCB machine physical address. 

But overall, the concept is pretty much the same. 

--
Mats
> -----Original Message-----
> From: Kaushik Barde [mailto:Kaushik_Barde@Phoenix.com] 
> Sent: 15 February 2007 20:33
> To: Petersson, Mats; aditya shevalkar; xen devel
> Subject: RE: [Xen-devel] Communication between guest OS and VMM
> 
> 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@amd.com] 
> 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@lists.xensource.com 
> > [mailto:xen-devel-bounces@lists.xensource.com] 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@lists.xensource.com
> > [mailto:xen-devel-bounces@lists.xensource.com] 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@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> > 
> > 
> 
> 
> 


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

Possibly Parallel Threads

Search for more possibly parallel threads

Xen devel - Feb 2007 - Communication between guest OS and VMM

[Xen-devel] Communication between guest OS and VMM

RE: [Xen-devel] Communication between guest OS and VMM

RE: [Xen-devel] Communication between guest OS and VMM

RE: [Xen-devel] Communication between guest OS and VMM

Re: [Xen-devel] Communication between guest OS and VMM

RE: [Xen-devel] Communication between guest OS and VMM

RE: [Xen-devel] Communication between guest OS and VMM

Re: [Xen-devel] Communication between guest OS and VMM

RE: [Xen-devel] Communication between guest OS and VMM

Possibly Parallel Threads