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 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> ?



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