aditya shevalkar
2007-Feb-19 11:07 UTC
[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:
Event channels,
Shared memory,
Grant Tables,
XenStore,
Xen daemon,
Device data(I/O).
( How does this IO data is transferred between guest OS windows XP
and Xen VMM in case of full virtualization).
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@lists.xensource.com
http://lists.xensource.com/xen-devel
Petersson, Mats
2007-Feb-19 11:55 UTC
RE: [Xen-devel] Can anyone explain this communication mechanisms in case of full virtualization.
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] 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@lists.xensource.com > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel