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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

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