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/
Home Products Support Community News


[Xen-devel] [PATCH RFC 0/5] Grant table for console, xenstore pages

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [PATCH RFC 0/5] Grant table for console, xenstore pages
From: Diego Ongaro <diego.ongaro@xxxxxxxxxx>
Date: Fri, 11 Jul 2008 20:12:30 +0100
Delivery-date: Fri, 11 Jul 2008 12:12:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird (X11/20080509)
I'm working on moving xenstored into a dedicated, unprivileged domain.
This is the first set of patches I'm sending out towards that goal. I
understand there is currently a freeze, so I'm just looking for feedback
at this point.

Each domU shares one of its pages with the xenstore daemon from its
creation. The domain builder writes the mfn for this page in the domU's
start info page. Then it sends the xenstore daemon an "introduce"
command, giving it the new domU's domid, this mfn to map, and an unbound
port in the domU to bind.

However, if the xenstore daemon resides in an unprivileged domain, it is
not permitted to map an arbitrary mfn. Instead, it could use the
existing grant table mechanism. In fact, the first 8 grant table entries
for each domU are reserved for cases like this. (DomU's don't use the
first 8 entries.)

Because the console and the xenstore mechanisms are so similar, these
patches include analogous changes for console support as well.

The first patch claims one grant entry for the console and another for
the xenstore. It modifies the builder to fill in the grant table entries
for the console and the xenstore. At this stage, the grant entries just
give access to domain 0 (addressed in a later patch).

The next two patches modify the xenstore daemon and the console daemon,
respectively, to use xc_gnttab_map_grant_ref instead of

The final two patches implement a way to determine in which domains the
console and xenstore daemons reside. If each of the files
/var/run/{console,xenstore}.did contains an integer, this integer is
interpreted as the domain id for that daemon. The default or fallback is
domid=0, of course. In patch 4, libxc is modified to use this mechanism
for the grant table entries. In patch 5, xend is modified to use this
mechanism for the allocated unbound ports.

To get the discussion going, what should be done about xenstore's
/local/domain/#/device/{console,store}/ring-ref ? I don't think they're
necessary anymore, but I've made no effort to remove them.

Diego Ongaro

Xen-devel mailing list