From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xenproject.org, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [PATCH RFC 04/12] libxl: create a local xenstore libxl and device-model dir for guests
Date: Thu, 26 Sep 2013 11:57:00 +0200 [thread overview]
Message-ID: <524404EC.6030805@citrix.com> (raw)
In-Reply-To: <1380188363.29483.27.camel@kazak.uk.xensource.com>
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).
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-09-26 9:57 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-23 10:30 [PATCH RFC 00/12] libxl: add driver domain backend daemon Roger Pau Monne
2013-09-23 10:30 ` [PATCH RFC 01/12] libxl/hotplug: add support for getting domid Roger Pau Monne
2013-09-25 13:50 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 02/12] libxl: remove unneeded libxl_domain_info in wait_device_connection Roger Pau Monne
2013-09-25 13:51 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 03/12] libxl: make hotplug execution conditional on backend_domid == domid Roger Pau Monne
2013-09-25 13:52 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 04/12] libxl: create a local xenstore libxl and device-model dir for guests Roger Pau Monne
2013-09-25 13:48 ` Ian Campbell
2013-09-26 9:27 ` Roger Pau Monné
2013-09-26 9:39 ` Ian Campbell
2013-09-26 9:57 ` Roger Pau Monné [this message]
2013-09-26 10:15 ` Ian Campbell
2013-09-26 10:20 ` Roger Pau Monné
2013-09-26 10:26 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 05/12] libxl: don't remove device backend path if not local Roger Pau Monne
2013-09-25 13:54 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 06/12] libxl: set correct permissions for the full backend path Roger Pau Monne
2013-09-25 13:57 ` Ian Campbell
2013-09-25 14:02 ` Roger Pau Monné
2013-09-25 15:00 ` Ian Campbell
2013-09-25 15:10 ` Roger Pau Monné
2013-09-25 15:18 ` Ian Campbell
2013-09-26 9:20 ` Roger Pau Monné
2013-09-26 9:24 ` Ian Campbell
2013-09-26 9:30 ` Roger Pau Monné
2013-09-26 9:39 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 07/12] libxl: remove the Qemu bodge for driver domain devices Roger Pau Monne
2013-09-23 10:30 ` [PATCH RFC 08/12] libxl: don't launch Qemu on Dom0 for Qdisk devices on driver domains Roger Pau Monne
2013-09-25 15:06 ` Ian Campbell
2013-09-25 15:13 ` Roger Pau Monné
2013-09-23 10:30 ` [PATCH RFC 09/12] libxl: add Qdisk backend launch helper Roger Pau Monne
2013-09-23 10:30 ` [PATCH RFC 10/12] xl: put daemonize code in it's own function Roger Pau Monne
2013-09-23 10:30 ` [PATCH RFC 11/12] libxl: revert 326a7b74 Roger Pau Monne
2013-09-23 10:30 ` [PATCH RFC 12/12] libxl: add device backend listener in order to launch backends Roger Pau Monne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=524404EC.6030805@citrix.com \
--to=roger.pau@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).