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
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
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
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
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
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
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
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
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