RE: [Xen-devel] Can anyone explain this communication mechanisms in case of full virtualization.

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

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> aditya shevalkar
> Sent: 19 February 2007 11:08
> To: xen devel
> Subject: [Xen-devel] Can anyone explain this communication 
> mechanisms in case of full virtualization.
> 
> For the communication between guest OS(windows OS) and xen 
> VMM in full virtualization how does the following 
> Concepts are used/implemented or what are the equivalent of 
> these concepts in case of full virtualization:

Let's set the scenario that we're NOT using para-virtual drivers - i.e.
using a "shrink wrapped Microsoft Windows CD/DVD" - because using
para-virtual drivers pretty much confuses the situation, and that's
making it MUCH harder to explain. 

> Event channels,
Windows doesn't use event-channels in communicating with the VMM. 

Qemu-dm uses event-channels to synchronously receive device-IO
"instructions", and asynchronously "fire" interrupts to the guest via
the VMM (the VMM checks the event-channel and issues a "virtual
interrupt" which is part of the Virtualization Technology (AMD-V/Intel
VT)).

> Shared memory,
Shared memory is used to implement graphics display. The way that works
is that QEMU-DM sets up an area of memory, which is mapped to the
address of the graphics cards memory. QEMU-DM also has a "scanner"
process that checks if the "video memory" has changed, and if so,
updates the displayed data. 

Windows itself isn't aware that this is shared-memory in any sense
(other than the same sense that video-memory is "shared" with the
graphics processor in the graphics card in general, although for the
video-card that is emulated by qemu, this is at such a low level of
sophistication that it can be ignored). 

QEMU-DM also shares ALL of the guest-memory [1], using
xc_map_foreign_range

>      Grant Tables,
There is no grant-table usage in Windows. 

I'm not sure if qemu-dm uses grant-tables. I have a feeling the answer
is no - I couldn't find anything obvious. 

> XenStore,
XenStore isn't used by Windows. 

QEMU-DM uses XenStore to get configuration data from the store (as
stored by xend).

>      Xen daemon,

Xend is used to create, pause, restart and destroy the domain. Via the
emulated power-management functions in QEMU-DM, the guest is also able
to "shutdown" and "reboot", which is signaled to xend for further action
(such as destroying the domain or restarting it). 

Xend also populates xenstore entries for the domain, so that later on
qemu-dm can get the data out, and so that we can perform XM commands
that require xenstore data (for example xm list). 

>      Device data(I/O).
> (    How does this IO data is transferred between guest OS windows XP 
>      and Xen VMM in case of full virtualization).

VMM intercepts I/O operations (either IOIO or MMIO). The data in this
case can be in:
1. In a CPU register (these are saved when the guest is exiting back to
VMM). Depending on the operation, it's possible that VMM has to
interpret the machine-code in the guest to understand which operation it
was that was being performed - for example a page-fault cause by MMIO to
a virtual device, would need to be interpreted, as there are literally
hundreds of different combinations of memory access instructions that
could cause this (including "read-modify-write" operations, for example
"add %eax, (mmio_addr)" - in which case we ALSO need to know the MMIO
content to figure out the new value). 

2. In guest memory. For example IOIO instructions INS/OUTS or MMIO
instructions MOVS would have a memory address assoicated with the data
to be sent to the device. In case of these instructions. the data is
pointed to by specific registers for each instruction, so it's easy for
the code to figure out what the address of the data is.




[1] In the current unstable release of Xen, there is a slightly
different, dynamic mapping, scheme, where the guest memory is mapped in
"as necessary", rather than "all at all times". This is helpful for
several reasons, most importantly because QEMU-DM don't have enough
address space to map much over 2.5GB in 32-bit mode (qemu-dm itself uses
some, and Linux limits the guest memory to 3GB in total). 

--
Mats


> Specially Shared memory,grant tables and xen store.
> Does all these concepts applicable to full virtualization case also?
> Are their any other mechanisms for the communication(direct 
> or indirect).
>  
> 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