On 10/12/2011 12:32 PM, Ian Campbell wrote:
> On Tue, 2011-10-11 at 15:52 +0100, Daniel De Graaf wrote:
>> On 10/10/2011 08:54 AM, Ian Campbell wrote:
>>> On Fri, 2011-10-07 at 17:37 +0100, Daniel De Graaf wrote:
>>>> On 10/07/2011 03:52 AM, Ian Campbell wrote:
>>>>> On Thu, 2011-10-06 at 19:32 +0100, Daniel De Graaf wrote:
>>>>>> On 10/06/2011 01:53 PM, Ian Jackson wrote:
>>>>>>> Daniel De Graaf writes ("[Xen-devel] [PATCH] xenbus: Fix loopback event
>>>>>>> channel assuming domain 0"):
>>>>>>>> The xenbus event channel established in xenbus_init is intended to be a
>>>>>>>> loopback channel, but the remote domain was hardcoded to 0; this will
>>>>>>>> cause the channel to be unusable when xenstore is not being run in
>>>>>>>> domain 0.
>>>>>>>
>>>>>>> I'm not sure I understand this.
>>>>>>>
>>>>>>> ...
>>>>>>>> /* Next allocate a local port which xenstored can bind
>>>>>>>> to */
>>>>>>>> alloc_unbound.dom = DOMID_SELF;
>>>>>>>> - alloc_unbound.remote_dom = 0;
>>>>>>>> + alloc_unbound.remote_dom = DOMID_SELF;
>>>>>>>
>>>>>>> The comment doesn't suggest that this is supposedly a loopback channel
>>>>>>> (ie one for use by the xenbus client for signalling to itself,
>>>>>>> somehow).
>>>>>>
>>>>>> The event channel being changed here is a loopback event channel exposed
>>>>>> in
>>>>>> /proc/xen/xsd_port, which xenstored binds to. This code is only used for
>>>>>> the
>>>>>> initial domain; otherwise, the shared info page is used.
>>>>>
>>>>> How does this change impact the regular dom0? It will be expecting a
>>>>> xenstored to startup locally when in reality it actually needs to wait
>>>>> for another domain and then connect to that.
>>>>
>>>> This change does not attempt to address the regular dom0, except for not
>>>> breaking existing setups where xenstored resides in dom0.
>>>>
>>>>> Diego Ongaro did some work several years ago on this issue, it was most
>>>>> recently re-posted by Alex Zeffert, patches against xen-unstable and the
>>>>> linux-2.6.18 tree:
>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01484.html
>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01488.html
>>>>>
>>>>> Part of the trick was to fixup the kernel side in a way which was
>>>>> compatible with both existing Xen releases while also supporting new
>>>>> releases which support both stub and non-stub xenstore. To do this Diego
>>>>> setup a lazy xenbus initialisation with a state machine to track which
>>>>> case was active, with transitions triggered either from the local-mmap
>>>>> of /proc/xen/xenbus_xsd (so was backwards compatible) or an ioctl called
>>>>> by the tool which builds the stub domain to tell the dom0 xenbus code
>>>>> which domain/mfn/evtchn contains the xenstored and dom0's connection to
>>>>> it (the patcheset includes a cut-down builder which works without
>>>>> xenstore).
>>>>>
>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01487.html
>>>>> is the key kernel side patch in that regard.
>>>>>
>>>>> Diego did some initial work with xenstored in a Linux domU, but I think
>>>>> the final patchset was stub-xenstored (i.e. ocaml xenstored on minios,
>>>>> possibly C xenstored on minios too), so I'm not sure about the xenstored
>>>>> in Linux domU use case.
>>>>>
>>>>> Some of the more trivial bits of this series were committed but the real
>>>>> meat wasn't really pushed through.
>>>>>
>>>>
>>>> Thanks for pointing out that series; I hadn't seen it yet. The setup I am
>>>> currently using has a non-Linux dom0, so the state machine in dom0 was not
>>>> required. A separate minios-based xenstored is the eventual goal; this
>>>> patch
>>>> just avoids creating a broken event channel in an initial domain whose
>>>> domain ID is not 0.
>>>
>>> Although I suspect it was envisaged when the API was written I don't
>>> think SIF_INITDOMAIN can actually be used (or redefined) to mean
>>> anything other than dom0 in practice without a whole host of knock-on
>>> effects and breakage.
>>>
>>> Setting SIF_INITDOMAIN has effects other than xenstore setup on a Linux
>>> domU, grepping for other uses of xen_initial_domain() shows loads of
>>> them. e.g. the selection of host vs. pseudo-physical e820, various
>>> driver setup stuff, some pagetable features, how the console works etc.
>>
>> Yes; splitting up driver domains requires changing a number of users of
>> xen_initial_domain to become more fine-grained. Some disaggregation work[1]
>> requires splitting the SIF_INITDOMAIN flag into a series of finer-grained
>> flags that includes one for xenstore; this becomes unnecessary if xenstore
>> detection code does not check SIF_INITDOMAIN.
>>
>> This patch covers a few cases:
>>
>> 1) Dom0 is Linux, xenstored runs in Dom0
>> 2) Dom0 is domain builder, creating another SIF_INITDOMAIN Linux domain with
>> a nonzero domain ID that runs xenstore and other functions
>> 3) Dom0 is domain builder, creating xenstore and a SIF_INITDOMAIN Linux
>> domain that uses the external xenstore.
>>
>> The second and third case require fairly intrusive hypervisor patches,
>
> What sort of hypervisor patches?
>
> I'm not convinced that the concept of "another SIF_INITDOMAIN" is
> possible. Certainly you might have other domains which have some
> privileges which have previously been associated with the domain whose
> ID is 0, but that does not imply that you should/can literally pass
> SIF_INITDOMAIN to those domains.
>
The patches add a "hardware domain" parameter which is passed control of the
hardware instead of dom0. This domain is in charge of most of the ACPI and
other nonspecific hardware devices, while individual PCI devices will be
passed to other driver domains (that are not SIF_INITDOMAIN).
The domain with ID 0 only acts as a domain builder here: it does not directly
access the hardware, only creating and activating other domains. This allows
domains (including xenstore and a few others) to start before the Linux domain
accessing the hardware has started any part of userspace.
>> but
>> the only Linux change required for the second case is the posted fix to the
>> loopback event channel.
>
> Unless dom0 is also running Linux? In which case it has no way to talk
> to the xenstored in the second domain?
Correct; I am not addressing this problem as dom0 is not running Linux here.
The other patches you pointed to do address that possibility with the ioctl,
which seems a good solution if you want to also run Linux in dom0 - although
in that case, dom0 may need to be marked as not SIF_INITDOMAIN to avoid trying
to set up hardware twice.
> Does the kernel the the "another SIF_INITDOMAIN" not get quite upset wrt
> it's ability to see physical hardware and such, which it will be
> confused about because you've given it SIF_INITDOMAIN?
The hypervisor patches actually give it the access required.
>> [1] "Breaking Up is Hard to Do: Security and Functionality in a Commodity
>> Hypervisor" (SOSP 11)
>>
>>>
>>>> I do have a more complex version of this patch that replaces the initial
>>>> domain check with a check on the start_info structure so that an initial
>>>> domain can have xenstore information placed in its start_info field like
>>>> any other domain; would this be of interest?
>>>
>>> If you already have something then it would be interesting to see.
>>>
>>> Ian.
>>>
>>
>> This patch eliminates xen_initial_domain() checks when initializing
>> xenstore, replacing them with checks on the event channel in the
>> start_info page.
>
> In your scenario 2 and 3 then with this patch the dom0 kernel will see
> no evtchn in start_info page but there appears to be no mechanism for
> poking down the evtchn/mfn for dom0 to use to communicate with the
> xenstored domain.
>
> I think that a combination of this patch and Diego's stuff (reapplied to
> your xenstored_local_init case) would catch all those combinations and
> work for both the real dom0 (with or without xenstored in it) and also a
> domN Linux domain running xenstored too. I think this patch by itself
> doesn't make any existing cases wrong nor make adding Diego's stuff in
> the future any harder.
>
> How does the xenstored running in the second domain get the necessary
> page/evtchn numbers to allow it to communicate with dom0?
In my setup, it doesn't ever communicate with dom0 as dom0 dies once it
has set up the boot domains. For a more general case, the page/evtchn
numbers could be passed in a normal introduce message if they are made
available outside dom0 (perhaps by command-line parameters or via another
mechanism like v4v).
> I assume it is guaranteed that xen_start_info->store_evtchn == 0 (and
> presumably xen_start_info->store_mfn == 0) for the real dom0?
Yes; the start_info page is zeroed prior to filling it in for dom0, and
these fields are not filled in.
--
Daniel De Graaf
National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home