Re: [Xen-devel] [PATCH RFC 04/12] libxl: create a local xenstore libxl and device-model dir for guests

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-09-26 at 12:20 +0200, Roger Pau Monnà wrote:
> On 26/09/13 12:15, Ian Campbell wrote:
> > On Thu, 2013-09-26 at 11:57 +0200, Roger Pau Monnà wrote:
> >> On 26/09/13 11:39, Ian Campbell wrote:
> >>> On Thu, 2013-09-26 at 11:27 +0200, Roger Pau Monnà wrote:
> >>>> On 25/09/13 15:48, Ian Campbell wrote:
> >>>>> On Mon, 2013-09-23 at 12:30 +0200, Roger Pau Monne wrote:
> >>>>>> If libxl is executed inside a guest domain it needs write access to
> >>>>>> the local libxl xenstore dir (/local/<domid>/libxl) to store internal
> >>>>>> data.
> >>>>>
> >>>>> These sorts of changes need a patch against docs/misc/xenstore-paths.txt
> >>>>> too.
> >>>>
> >>>> Ack.
> >>>>
> >>>>>
> >>>>>>  This also applies to Qemu which needs a
> >>>>>> /local/<domid>/device-model xenstore directory.
> >>>>>
> >>>>> Is this a new requirement or a separate preexisting issue? How have we
> >>>>> lived without it?
> >>>>
> >>>> This entry is so far only created on Dom0 (because it's the only domain
> >>>> that launches Qemu, and is created by Qemu if needed), but when running
> >>>> on a guest, the guest doesn't have permissions to write on
> >>>> /local/<domid>/, so we have to create the directory in the toolstack
> >>>> domain and assign write permissions for the guest.
> >>>>
> >>>> This path is hardcoded in Qemu, so it's quite difficult to change it,
> >>>> that's why I've opted for creating it on domain creation.
> >>>
> >>> OK :-/
> >>>
> >>>>>> This patch creates the mentioned directories for each guest launched
> >>>>>> from libxl.
> >>>>>
> >>>>> I don't really like leaking toolstack "internals" into the normal guest
> >>>>> namespace. Can we add an option to specify "this is a toolstack domain"
> >>>>> and key off that?
> >>>>
> >>>> OK, something like driver_domain=1|0
> >>>
> >>> Something like that, yes.
> >>>
> >>>>> I also wonder if this shouldn't be /libxl/<domid> at the top level.
> >>>>
> >>>> I don't have a strong opinion on this, but I generally prefer to keep
> >>>> all the xenstore related keys for a domain inside /libxl/<domid>.
> >>>
> >>> Are you agreeing with me or did you mean /local/(domain/)<domid> ?
> >>
> >> I would prefer to place it in /local/domain/<domid>/libxl/ because I get
> >> the feeling it's more contained, but frankly I don't have a strong
> >> opinion on this, if you prefer to use /libxl/<domid> I can go for it.
> >>
> >> However keep in mind that we will have to create the
> >> /local/domain/<domid>/libxl dir anyway, because we have to write the
> >> hotplug disable key there (/local/domain/<domid>/libxl/disable_udev).
> > 
> > That's a toolstack "internal" key isn't it, which we can move? Or is it?
> 
> Yes, we can move it with some modifications to the hotplug scripts, but
> we will still need to create a directory like /libxl/<domid>/, or
> something similar where the guest has write permissions, but I don't see
> how this is any better than /local/domain/<domid>/libxl/.

I suppose as long as the path is clearly documented as for being for
code implementing dissagregated toolstack functionality (driver domains)
only then there's not much distinction. I thought the /libxl path was a
bit more "self enforcing/documenting" is all by being outside the
regular path.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel