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

["Kaushik Barde" <Kaushik_Barde@xxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Petersson,
Mats
Sent: Thursday, February 15, 2007 5:05 AM
To: aditya shevalkar
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] Communication between guest OS and VMM

 

> -----Original Message-----
> From: aditya shevalkar [mailto:aditya27783@xxxxxxxxxxx] 
> 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@xxxxxxx>
> To: Kaushik Barde <Kaushik_Barde@xxxxxxxxxxx>; aditya 
> shevalkar <aditya27783@xxxxxxxxxxx>; xen devel 
> <xen-devel@xxxxxxxxxxxxxxxxxxx>
> 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@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
> > 
> > 
> >
> 
> 
>               
> __________________________________________________________
> 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