| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] [RFC] [0/4] User-space grants for Console and XenStore
Following on from the introduction of a User-space grant table device
("gntdev" - see http://lists.xensource.com/archives/html/xen-devel/
2007-03/msg01337.html for more details), I have modified the domain
building process so that the grant table mechanism is used for
communication with the console and XenStore daemons. This replaces
the use of xc_map_foreign_range().
The development was carried out as follows:
* Added a new gnttabop, which installs grant table entries into the
reserved section of the grant table.
* Modified the domain builder to install entries for the console and
XenStore pages for each new domain (using fixed entry numbers).
* Modified the console and XenStore daemons to use
xc_gnttab_map_grant_ref() in place of xc_map_foreign_range().
I've tested this locally (on x86_32 and x86_64) and it seems to work.
There are a few remaining concerns that I have:
* Will this work on ia64 and PowerPC?
* How will this integrate with XSM? The install-grant operation is
clearly as privileged as the ability to map arbitrary memory from a
foreign domain, so could these share a hook?
* Solaris support? I don't know enough about Solaris to know what
changes must be made to gntdev for it to run there. Since these
changes hit presumably portable code, would it be acceptable to have
an #ifdef in the console and XenStore daemons?
The patch is structured as follows:
1. gnttabop.patch - Changes to the hypervisor to add the install-
entry gnttabop.
2. libxc.patch - Changes to libxc to install grants for the console
and XenStore pages.
3. xenconsoled.patch - Changes to the console daemon to use grant
references.
4. xenstored.patch - Changes to the XenStore daemon to use grant
references.
I would welcome your input on this.
Regards,
Derek Murray.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home