[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen newbie: inter-domain communication



> 1. As far as I can understand (and I might be wrong) Xen maintains two
> domains dom0 (control domain) and dom1 (the other guest OSes). When the
> documentation says inter-domain communication, is it only referring to the
> communication between the dom0 and dom1, or it can also be applied to the
> communication among the guest OSes (unprivileged that is).

As another poster said a "domain" is the execution context a virtual machine 
runs in, similar to how a "process" is the execution context a UNIX program 
runs in.  Each VM exists in it's own domain.

Domain 0 is a special case - it's the domain that happens to get control of 
the real physical hardware.  "Domain 1" is a colloquial term we often use to 
refer to a domain that isn't dom0 ;-)

There are various kinds of "Interdomain communication".

1) the virtual network interface
2) the virtual block interface
3) the control interface

Each of these uses an "event channel" (inter-domain interrupt) and page of 
shared memory.  Each has its own protocol.  Other types of interface will use 
their own protocol, as suited to that device.

Typically these occur between dom0 and other domains.  More complicated 
connectivity might occur, e.g. if you're using driver domains.

> 2. What are the capabilities of the inter-domain communication method.
> Specifically: what protocol is used to communicate?, 

Each interface uses a ring buffer into which small messages are inserted.  
These messages are defined as structs in the header files in 
xen/include/public/io/, which basically define much of the protocol.

You'd have to look at the source for the netif / blkif / ctrlif drivers to see 
how it all works.

For the network and block interfaces, the information in these messages is 
used to direct DMA transfers directly into / out of guest memory.

> what kind of 
> information can be communicated?

For block and net, information required to do the main IO transfer.  The 
control interface is used for generic control messaging (setting up devices, 
transferring console data, blah).

> Can this communication be used for 
> logging/auditing? Does anybody has any experience using this method or has
> any working example?

I seem to remember somebody was working on a secure logging framework.  I 
don't know how they're getting on, though.

> 3. When the domain save operation is done, Xen saves the memory image to a
> file and then uses it back to restore the domain (with xm save/restore
> commands). What is the format of this image file.

There's not an official spec, I'm afraid you'd have to look at the suspend 
code to figure out how the files are structured.

> Can it be read somehow to 
> know the status of the guest OS when it was hibernated?

Possible in principle.  One might (for instance) construct a tool that'd 
convert a suspend file into a core file, which you could then inspect using 
GDB.  Don't think this has been done, though.


> I would appreciate any help regarding these queries.

HTH,
Mark

>
> Thanks
>
> Chotu
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.