WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Kaushik Barde" <Kaushik_Barde@xxxxxxxxxxx>, "aditya shevalkar" <aditya27783@xxxxxxxxxxx>, "xen devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Communication between guest OS and VMM
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Fri, 16 Feb 2007 11:21:13 +0100
Delivery-date: Fri, 16 Feb 2007 02:20:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <0EF82802ABAA22479BC1CE8E2F60E8C30164BA85@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdQzIyu1YsUK4hpTqWNnxXlbSkA3QADtBqQAANrACAAFVzqgAAc2YDA
Thread-topic: [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@xxxxxxxxxxx] 
> 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@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
> > 
> > 
> > 
> 
> 
> 



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