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

["Derek Murray" <Derek.Murray@xxxxxxxxxxxx>]

Hi Diego,

I imagine you've already ready seen this, but the thread beginning
here has some historical context:

http://lists.xensource.com/archives/html/xense-devel/2007-05/msg00004.html

So the main points to note will be:
* The patches won't work on Dom0s without gntdev support (e.g. at
present Solaris, or older XenoLinux kernels). I'm not sure of the
current status but a question mark still hangs over gntdev in
pv_ops-Dom0, though your patches might give some impetus to find a
solution.
* Have you tested with domain save/restore? Apparently (per
http://lists.xensource.com/archives/html/xense-devel/2007-05/msg00011.html
), the grant table is reset upon restore, so you may need to reinstall
the grants for the console and XenStore.
* There was some argument against fixed grant references for the
console and store pages, though this would require modifying the
interface to the domain builder.

I would imagine, considering the previous discussion, that you may
want to retain the existing ring-ref values, and it should be possible
to continue with the old method. Apart from that, the idea and
implementation look pretty sound!

Regards,

Derek Murray.

On Fri, Jul 11, 2008 at 8:12 PM, Diego Ongaro <diego.ongaro@xxxxxxxxxx> wrote:
> 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
> xc_map_foreign_range.
>
> 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.
>
> Thanks,
> Diego Ongaro
>
> _______________________________________________
> 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