Re: [Xen-devel] making xenstore domain easy configurable

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 28/06/16 12:56, Juergen Gross wrote:
> On 28/06/16 13:03, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
>> configurable"):
>>> So you are telling me the xenstore domain won't work for this case?
>> Yes.
> That's rather unfortunate. So in order to be able to make xenstore
> domain a common setup we need to find a solution for support of
> xs_restrict() via xenbus, right?
>
> TBH, the way xs_restrict() was introduced is rather weird. It is
> completely bound to the socket interface of oxenstored. So anyone
> wanting to use xs_restrict() is limited to oxenstored running in
> dom0. No way to use xenstored or a xenstore domain. I'm really
> disappointed such a design was accepted and is now the reason for
> not being able to disaggregate dom0.
>
> I've searched through the xen-devel archives and found a very
> interesting mail:
>
> http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html
>
> The "restrict" feature was added without any further discussion how
> it is implemented and that the C-variant doesn't support it. The
> explicit question about non-existing features in the C xenstored was
> answered just with "the xenstore wire protocol doesn't change".
>
> With:
>
> http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html
>
> the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
> was added. Again no mentioning of the special implementation in
> oxenstored.
>
> Really, this is not how open source development should be done!
> Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
> support as it has been introduced in a foul way.

I don't think the lack of xs_restrict() working over the ring should
preclude these improvements to the configuration of how xenstored starts up.

Ideally, this issue would be listed in an appropriate place in
docs/features/, in the hope that it gets considered and addressed in the
future.

However, the xs_restrict() library function will clearly fail in some
way when cxenstored is in use, and nothing currently uses it, so the
lack of it also working when using a xenstored stubdomain doesn't
constitute a reduction in functionality.


Longterm, a sensible solution would be to make a xenstore protocol
extension to wrap an existing xenstore message in a restrict wrapper,
where the kernel device can apply the appropriate restrict around user
requests.  This isn't the only protocol extension required; there is an
existing problem XenServer has hit that a xenstore-ls response when
enough domains are running will exceed XENSTORE_MAX_PAYLOAD, and fail. 
Someone is going to have to fix that at some point - might as well do
these both at once.

~Andrew

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