making xenstore domain easy configurable

making xenstore domain easy configurable

[Juergen Gross]

I'm just writing some patches to make it easy to switch between
xenstore daemon and xenstore domain. My plan is to achieve this
by a global configuration file containing configuration options
for the host (e.g. /etc/xen/xen.conf).

With the current systemd support this is not easy. There are
systemd socket definitions to let systemd create the sockets for
xenstored. As the sockets are not to be created in case xenstore
is running in a xenstore domain things are becoming complicated.

Today we have the following xenstore related systemd items:

- xenstored_ro.socket and xenstored.socket
- xenstored.service depending on the sockets
- other services depending on xenstored.service

A xenstore domain would need:

- xenstore-domain.service
- other services depending on xenstore-domain.service

Being able to switch between both schemes just via a config file
seems to be not easy, at least I don't know of any way to do the
socket creation only in case they are required without breaking
the dependency chain.

So I'd suggest to remove xenstored_ro.socket and xenstored.socket
and let xenstored create the sockets (as it is doing without
systemd). I'm not aware of any disadvantage, as xenstored isn't
restartable and thus can't take advantage of the permanent sockets
offered by systemd.

This would mean I could rip out the systemd specific stuff from
xenstored and oxenstored. I could create a single xenstore.service
script evaluating the config file and starting the correct xenstore
(xenstored or xenstore domain). The other services would then depend
on xenstore.service. This would remove the need to specify the
type of xenstore daemon/domain (ocaml based or C based) in the systemd
file, too.

Is there a better way to achieve what I want? Any other opinions?


Juergen

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

Re: making xenstore domain easy configurable

[Andrew Cooper]

On 27/06/16 13:43, Juergen Gross wrote:
> I'm just writing some patches to make it easy to switch between
> xenstore daemon and xenstore domain. My plan is to achieve this
> by a global configuration file containing configuration options
> for the host (e.g. /etc/xen/xen.conf).
>
> With the current systemd support this is not easy. There are
> systemd socket definitions to let systemd create the sockets for
> xenstored. As the sockets are not to be created in case xenstore
> is running in a xenstore domain things are becoming complicated.
>
> Today we have the following xenstore related systemd items:
>
> - xenstored_ro.socket and xenstored.socket
> - xenstored.service depending on the sockets
> - other services depending on xenstored.service
>
> A xenstore domain would need:
>
> - xenstore-domain.service
> - other services depending on xenstore-domain.service
>
> Being able to switch between both schemes just via a config file
> seems to be not easy, at least I don't know of any way to do the
> socket creation only in case they are required without breaking
> the dependency chain.
>
> So I'd suggest to remove xenstored_ro.socket and xenstored.socket
> and let xenstored create the sockets (as it is doing without
> systemd). I'm not aware of any disadvantage, as xenstored isn't
> restartable and thus can't take advantage of the permanent sockets
> offered by systemd.
>
> This would mean I could rip out the systemd specific stuff from
> xenstored and oxenstored. I could create a single xenstore.service
> script evaluating the config file and starting the correct xenstore
> (xenstored or xenstore domain). The other services would then depend
> on xenstore.service. This would remove the need to specify the
> type of xenstore daemon/domain (ocaml based or C based) in the systemd
> file, too.
>
> Is there a better way to achieve what I want? Any other opinions?

This isn't the only advantage offered by socket activation.

As currently configured, every service which depends on xenstored.socket
can be started in parallel (as systemd creates the sockets ahead of
time), with the dependent services blocking a little on the socket while
xenstored starts up sufficiently to service the requests.

In the case that xenstored is running in the local domain, socket
activation is a useful function to have.

OTOH, having anything explicitly depend on xenstored.socket is broken in
a model where xenstored might be running in a separate domain.  I don't
suppose systemd has any way of specifying "conditionally might have a
socket"?

~Andrew

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

Re: making xenstore domain easy configurable

[Juergen Gross]

On 27/06/16 14:59, Andrew Cooper wrote:
> On 27/06/16 13:43, Juergen Gross wrote:
>> I'm just writing some patches to make it easy to switch between
>> xenstore daemon and xenstore domain. My plan is to achieve this
>> by a global configuration file containing configuration options
>> for the host (e.g. /etc/xen/xen.conf).
>>
>> With the current systemd support this is not easy. There are
>> systemd socket definitions to let systemd create the sockets for
>> xenstored. As the sockets are not to be created in case xenstore
>> is running in a xenstore domain things are becoming complicated.
>>
>> Today we have the following xenstore related systemd items:
>>
>> - xenstored_ro.socket and xenstored.socket
>> - xenstored.service depending on the sockets
>> - other services depending on xenstored.service
>>
>> A xenstore domain would need:
>>
>> - xenstore-domain.service
>> - other services depending on xenstore-domain.service
>>
>> Being able to switch between both schemes just via a config file
>> seems to be not easy, at least I don't know of any way to do the
>> socket creation only in case they are required without breaking
>> the dependency chain.
>>
>> So I'd suggest to remove xenstored_ro.socket and xenstored.socket
>> and let xenstored create the sockets (as it is doing without
>> systemd). I'm not aware of any disadvantage, as xenstored isn't
>> restartable and thus can't take advantage of the permanent sockets
>> offered by systemd.
>>
>> This would mean I could rip out the systemd specific stuff from
>> xenstored and oxenstored. I could create a single xenstore.service
>> script evaluating the config file and starting the correct xenstore
>> (xenstored or xenstore domain). The other services would then depend
>> on xenstore.service. This would remove the need to specify the
>> type of xenstore daemon/domain (ocaml based or C based) in the systemd
>> file, too.
>>
>> Is there a better way to achieve what I want? Any other opinions?
> 
> This isn't the only advantage offered by socket activation.
> 
> As currently configured, every service which depends on xenstored.socket
> can be started in parallel (as systemd creates the sockets ahead of
> time), with the dependent services blocking a little on the socket while
> xenstored starts up sufficiently to service the requests.

Okay, but this isn't true for the xenstore domain case, resulting in the
need for an explicit dependency then. I don't think doing the same for
xenstored is adding too much time to system startup.

> In the case that xenstored is running in the local domain, socket
> activation is a useful function to have.
> 
> OTOH, having anything explicitly depend on xenstored.socket is broken in
> a model where xenstored might be running in a separate domain.  I don't
> suppose systemd has any way of specifying "conditionally might have a
> socket"?

I don't know of any way to do this.


Juergen


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

Re: making xenstore domain easy configurable

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 3224 bytes --]

On 6/27/16 7:59 AM, Andrew Cooper wrote:
> On 27/06/16 13:43, Juergen Gross wrote:
>> I'm just writing some patches to make it easy to switch between
>> xenstore daemon and xenstore domain. My plan is to achieve this
>> by a global configuration file containing configuration options
>> for the host (e.g. /etc/xen/xen.conf).
>>
>> With the current systemd support this is not easy. There are
>> systemd socket definitions to let systemd create the sockets for
>> xenstored. As the sockets are not to be created in case xenstore
>> is running in a xenstore domain things are becoming complicated.
>>
>> Today we have the following xenstore related systemd items:
>>
>> - xenstored_ro.socket and xenstored.socket
>> - xenstored.service depending on the sockets
>> - other services depending on xenstored.service
>>
>> A xenstore domain would need:
>>
>> - xenstore-domain.service
>> - other services depending on xenstore-domain.service
>>
>> Being able to switch between both schemes just via a config file
>> seems to be not easy, at least I don't know of any way to do the
>> socket creation only in case they are required without breaking
>> the dependency chain.
>>
>> So I'd suggest to remove xenstored_ro.socket and xenstored.socket
>> and let xenstored create the sockets (as it is doing without
>> systemd). I'm not aware of any disadvantage, as xenstored isn't
>> restartable and thus can't take advantage of the permanent sockets
>> offered by systemd.
>>
>> This would mean I could rip out the systemd specific stuff from
>> xenstored and oxenstored. I could create a single xenstore.service
>> script evaluating the config file and starting the correct xenstore
>> (xenstored or xenstore domain). The other services would then depend
>> on xenstore.service. This would remove the need to specify the
>> type of xenstore daemon/domain (ocaml based or C based) in the systemd
>> file, too.
>>
>> Is there a better way to achieve what I want? Any other opinions?
> 
> This isn't the only advantage offered by socket activation.
> 
> As currently configured, every service which depends on xenstored.socket
> can be started in parallel (as systemd creates the sockets ahead of
> time), with the dependent services blocking a little on the socket while
> xenstored starts up sufficiently to service the requests.
> 
> In the case that xenstored is running in the local domain, socket
> activation is a useful function to have.
> 
> OTOH, having anything explicitly depend on xenstored.socket is broken in
> a model where xenstored might be running in a separate domain.  I don't
> suppose systemd has any way of specifying "conditionally might have a
> socket"?
> 
> ~Andrew

How about we take this the other way? Let's go away from using the
socket and always go through kernel interface. I understand that its
faster to use sockets than using the interface but does this performance
difference really affect an actual running system. If we manage to steer
people towards a stubdom xenstore they won't have the option of using
the sockets anyway. Just thinking that supporting two different
interfaces always seems clumsy.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: making xenstore domain easy configurable

[Juergen Gross]

On 27/06/16 22:59, Doug Goldstein wrote:
> On 6/27/16 7:59 AM, Andrew Cooper wrote:
>> On 27/06/16 13:43, Juergen Gross wrote:
>>> I'm just writing some patches to make it easy to switch between
>>> xenstore daemon and xenstore domain. My plan is to achieve this
>>> by a global configuration file containing configuration options
>>> for the host (e.g. /etc/xen/xen.conf).
>>>
>>> With the current systemd support this is not easy. There are
>>> systemd socket definitions to let systemd create the sockets for
>>> xenstored. As the sockets are not to be created in case xenstore
>>> is running in a xenstore domain things are becoming complicated.
>>>
>>> Today we have the following xenstore related systemd items:
>>>
>>> - xenstored_ro.socket and xenstored.socket
>>> - xenstored.service depending on the sockets
>>> - other services depending on xenstored.service
>>>
>>> A xenstore domain would need:
>>>
>>> - xenstore-domain.service
>>> - other services depending on xenstore-domain.service
>>>
>>> Being able to switch between both schemes just via a config file
>>> seems to be not easy, at least I don't know of any way to do the
>>> socket creation only in case they are required without breaking
>>> the dependency chain.
>>>
>>> So I'd suggest to remove xenstored_ro.socket and xenstored.socket
>>> and let xenstored create the sockets (as it is doing without
>>> systemd). I'm not aware of any disadvantage, as xenstored isn't
>>> restartable and thus can't take advantage of the permanent sockets
>>> offered by systemd.
>>>
>>> This would mean I could rip out the systemd specific stuff from
>>> xenstored and oxenstored. I could create a single xenstore.service
>>> script evaluating the config file and starting the correct xenstore
>>> (xenstored or xenstore domain). The other services would then depend
>>> on xenstore.service. This would remove the need to specify the
>>> type of xenstore daemon/domain (ocaml based or C based) in the systemd
>>> file, too.
>>>
>>> Is there a better way to achieve what I want? Any other opinions?
>>
>> This isn't the only advantage offered by socket activation.
>>
>> As currently configured, every service which depends on xenstored.socket
>> can be started in parallel (as systemd creates the sockets ahead of
>> time), with the dependent services blocking a little on the socket while
>> xenstored starts up sufficiently to service the requests.
>>
>> In the case that xenstored is running in the local domain, socket
>> activation is a useful function to have.
>>
>> OTOH, having anything explicitly depend on xenstored.socket is broken in
>> a model where xenstored might be running in a separate domain.  I don't
>> suppose systemd has any way of specifying "conditionally might have a
>> socket"?
>>
>> ~Andrew
> 
> How about we take this the other way? Let's go away from using the
> socket and always go through kernel interface. I understand that its
> faster to use sockets than using the interface but does this performance
> difference really affect an actual running system. If we manage to steer
> people towards a stubdom xenstore they won't have the option of using
> the sockets anyway. Just thinking that supporting two different
> interfaces always seems clumsy.

Generally I like the idea.

Just did a basic test and it seems just to work:

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index d1e01ba..8d806cb 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -288,10 +288,12 @@ struct xs_handle *xs_open(unsigned long flags)
 {
        struct xs_handle *xsh = NULL;

+#if 0
        if (flags & XS_OPEN_READONLY)
                xsh = get_handle(xs_daemon_socket_ro());
        else
                xsh = get_handle(xs_daemon_socket());
+#endif

        if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
                xsh = get_handle(xs_domain_dev());

Doing "strace xenstore-ls" verified the tool is now using the kernel
interface in dom0 with xenstored running. Using "time xenstore-ls"
showed no performance drop (the numbers are rather low; if any
difference is really measurable the socket variant seems to be a
little bit slower).

My conclusion: I'm going this route (thanks, Doug!), patches will
follow soon.


Juergen

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

Re: making xenstore domain easy configurable

[David Vrabel]

On 27/06/16 21:59, Doug Goldstein wrote:
> On 6/27/16 7:59 AM, Andrew Cooper wrote:
>> On 27/06/16 13:43, Juergen Gross wrote:
>>> I'm just writing some patches to make it easy to switch between
>>> xenstore daemon and xenstore domain. My plan is to achieve this
>>> by a global configuration file containing configuration options
>>> for the host (e.g. /etc/xen/xen.conf).
>>>
>>> With the current systemd support this is not easy. There are
>>> systemd socket definitions to let systemd create the sockets for
>>> xenstored. As the sockets are not to be created in case xenstore
>>> is running in a xenstore domain things are becoming complicated.
>>>
>>> Today we have the following xenstore related systemd items:
>>>
>>> - xenstored_ro.socket and xenstored.socket
>>> - xenstored.service depending on the sockets
>>> - other services depending on xenstored.service
>>>
>>> A xenstore domain would need:
>>>
>>> - xenstore-domain.service
>>> - other services depending on xenstore-domain.service
>>>
>>> Being able to switch between both schemes just via a config file
>>> seems to be not easy, at least I don't know of any way to do the
>>> socket creation only in case they are required without breaking
>>> the dependency chain.
>>>
>>> So I'd suggest to remove xenstored_ro.socket and xenstored.socket
>>> and let xenstored create the sockets (as it is doing without
>>> systemd). I'm not aware of any disadvantage, as xenstored isn't
>>> restartable and thus can't take advantage of the permanent sockets
>>> offered by systemd.
>>>
>>> This would mean I could rip out the systemd specific stuff from
>>> xenstored and oxenstored. I could create a single xenstore.service
>>> script evaluating the config file and starting the correct xenstore
>>> (xenstored or xenstore domain). The other services would then depend
>>> on xenstore.service. This would remove the need to specify the
>>> type of xenstore daemon/domain (ocaml based or C based) in the systemd
>>> file, too.
>>>
>>> Is there a better way to achieve what I want? Any other opinions?
>>
>> This isn't the only advantage offered by socket activation.
>>
>> As currently configured, every service which depends on xenstored.socket
>> can be started in parallel (as systemd creates the sockets ahead of
>> time), with the dependent services blocking a little on the socket while
>> xenstored starts up sufficiently to service the requests.
>>
>> In the case that xenstored is running in the local domain, socket
>> activation is a useful function to have.
>>
>> OTOH, having anything explicitly depend on xenstored.socket is broken in
>> a model where xenstored might be running in a separate domain.  I don't
>> suppose systemd has any way of specifying "conditionally might have a
>> socket"?
>>
>> ~Andrew
> 
> How about we take this the other way? Let's go away from using the
> socket and always go through kernel interface. I understand that its
> faster to use sockets than using the interface but does this performance
> difference really affect an actual running system. If we manage to steer
> people towards a stubdom xenstore they won't have the option of using
> the sockets anyway. Just thinking that supporting two different
> interfaces always seems clumsy.

xs_restrict() which QEMU will be making use of requires the unix domain
socket.

So I don't think we want to go down this route unless xs_restrict() can
be made to work via the kernel interface as well.

David

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

Re: making xenstore domain easy configurable

[Ian Jackson]

David Vrabel writes ("Re: [Xen-devel] making xenstore domain easy configurable"):
> So I don't think we want to go down this route unless xs_restrict() can
> be made to work via the kernel interface as well.

It could, in principle, but it would have to be implemented in the
xenstore kernel driver in each dom0 kernel, and might involve a
protocol extension to convey the right information to xenstored.

I don't think this is a good direction to be going.

Ian.

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

Re: making xenstore domain easy configurable

[Juergen Gross]

On 28/06/16 12:45, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] making xenstore domain easy configurable"):
>> So I don't think we want to go down this route unless xs_restrict() can
>> be made to work via the kernel interface as well.
> 
> It could, in principle, but it would have to be implemented in the
> xenstore kernel driver in each dom0 kernel, and might involve a
> protocol extension to convey the right information to xenstored.
> 
> I don't think this is a good direction to be going.

So you are telling me the xenstore domain won't work for this case?

BTW: I couldn't spot the socket being a prerequisite in the C-variant
of xenstored. Is this an oxenstored only problem?


Juergen


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

Re: making xenstore domain easy configurable

[Ian Jackson]

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.

Ian.

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

Re: making xenstore domain easy configurable

[Juergen Gross]

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.


Juergen

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

Re: making xenstore domain easy configurable

[Andrew Cooper]

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@lists.xen.org
http://lists.xen.org/xen-devel

Re: making xenstore domain easy configurable

[Juergen Gross]

On 28/06/16 14:42, Andrew Cooper wrote:
> 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.

It is limiting the solution by not allowing me to drop the sockets
completely.

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

I'd rather let xs_restrict() work in a clean way: setup a new ring and
event channel with the appropriate privileges and let the connection
to xenstore run via this ring.


Juergen

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

Re: making xenstore domain easy configurable

[Andrew Cooper]

On 28/06/16 14:36, Juergen Gross wrote:
> On 28/06/16 14:42, Andrew Cooper wrote:
>> 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.
> It is limiting the solution by not allowing me to drop the sockets
> completely.

I don't think dropping the sockets completely is a sensible course of
action.  I had come the conclusion that you were just not going to use
them, as opposed to removing them entirely.

For xenstored running in the same domain as the toolstack, sockets are
less overhead than the shared memory ring, as no hypercalls are
involved.  There is also the unfortunate problem that one of the two
linux devices for xenstored *still* causes deadlocks when used; a
problem which is unresolved from Linux 3.14.

>
>> 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.
> I'd rather let xs_restrict() work in a clean way: setup a new ring and
> event channel with the appropriate privileges and let the connection
> to xenstore run via this ring.

Domains currently don't have any notion of multiple xenstore-rings to
the same domain.  Somewhere (i.e. in xenstored itself) there would have
to be some kind of hard upper limit to avoid resource exhaustion, and
guest kernels would still have to have some privileged way of
negotiating the setup.  Also, how do you plan to make any of this work
with xenstored not in a subdomain?

It is far easier, and IMO sensible, just to mux something new over the
existing ring.

~Andrew

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

Re: making xenstore domain easy configurable

[Juergen Gross]

On 28/06/16 15:59, Andrew Cooper wrote:
> On 28/06/16 14:36, Juergen Gross wrote:
>> On 28/06/16 14:42, Andrew Cooper wrote:
>>> 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.
>> It is limiting the solution by not allowing me to drop the sockets
>> completely.
> 
> I don't think dropping the sockets completely is a sensible course of
> action.  I had come the conclusion that you were just not going to use
> them, as opposed to removing them entirely.

If they are not going to be used they can be dropped, no?

Again: the main problem with the sockets is their systemd definition in
combination of their existence being used for the connection type with
xenstore (socket vs. kernel).

So either I always connect via the kernel making the sockets useless
(then I can remove them completely) or I have a way creating the
sockets only in case of the daemon case which is currently available
only by removing the systemd definition of the sockets.

> For xenstored running in the same domain as the toolstack, sockets are
> less overhead than the shared memory ring, as no hypercalls are
> involved.  There is also the unfortunate problem that one of the two
> linux devices for xenstored *still* causes deadlocks when used; a
> problem which is unresolved from Linux 3.14.

So this would mean we should keep the sockets and just remove their
systemd definition.

>>> 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.
>> I'd rather let xs_restrict() work in a clean way: setup a new ring and
>> event channel with the appropriate privileges and let the connection
>> to xenstore run via this ring.
> 
> Domains currently don't have any notion of multiple xenstore-rings to
> the same domain.  Somewhere (i.e. in xenstored itself) there would have
> to be some kind of hard upper limit to avoid resource exhaustion, and
> guest kernels would still have to have some privileged way of
> negotiating the setup.  Also, how do you plan to make any of this work
> with xenstored not in a subdomain?

The multiple ring setup should be allowed for dom0 (or similar
privileged domains) only in order to avoid resource exhaustion.
xs_restrict() is limited to dom0, too.

I haven't worked on a design for the implementation yet. I've just
presented a rough interface idea making it rather easy to distinguish
multiple instances by xenstore regardless whether those instances are
located in the same domain or not.


Juergen


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

Re: making xenstore domain easy configurable

[Andrew Cooper]

On 28/06/16 15:58, Juergen Gross wrote:
> On 28/06/16 15:59, Andrew Cooper wrote:
>> On 28/06/16 14:36, Juergen Gross wrote:
>>> On 28/06/16 14:42, Andrew Cooper wrote:
>>>> 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.
>>> It is limiting the solution by not allowing me to drop the sockets
>>> completely.
>> I don't think dropping the sockets completely is a sensible course of
>> action.  I had come the conclusion that you were just not going to use
>> them, as opposed to removing them entirely.
> If they are not going to be used they can be dropped, no?
>
> Again: the main problem with the sockets is their systemd definition in
> combination of their existence being used for the connection type with
> xenstore (socket vs. kernel).
>
> So either I always connect via the kernel making the sockets useless
> (then I can remove them completely) or I have a way creating the
> sockets only in case of the daemon case which is currently available
> only by removing the systemd definition of the sockets.
>
>> For xenstored running in the same domain as the toolstack, sockets are
>> less overhead than the shared memory ring, as no hypercalls are
>> involved.  There is also the unfortunate problem that one of the two
>> linux devices for xenstored *still* causes deadlocks when used; a
>> problem which is unresolved from Linux 3.14.
> So this would mean we should keep the sockets and just remove their
> systemd definition.

This seems like the best course of action, especially as it appears that
we don't make use of the systemd sockets in the way systemd likes.

As far as I can tell, this will cause xs_restrict() to work as it
currently does when you use oxenstored locally in dom0, in which case I
am happy that there is no net reduction in functionality.

~Andrew

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

Re: making xenstore domain easy configurable

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 3074 bytes --]

On 6/28/16 8:59 AM, Andrew Cooper wrote:
> On 28/06/16 14:36, Juergen Gross wrote:
>> On 28/06/16 14:42, Andrew Cooper wrote:
>>> 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.
>> It is limiting the solution by not allowing me to drop the sockets
>> completely.
> 
> I don't think dropping the sockets completely is a sensible course of
> action.  I had come the conclusion that you were just not going to use
> them, as opposed to removing them entirely.
> 
> For xenstored running in the same domain as the toolstack, sockets are
> less overhead than the shared memory ring, as no hypercalls are
> involved.  There is also the unfortunate problem that one of the two
> linux devices for xenstored *still* causes deadlocks when used; a
> problem which is unresolved from Linux 3.14.

Since Xen 4.7 the broken devices won't be used by default. I understand
that the socket interface is faster and less overhead but I guess my
question is how much data is sent over this interface? Does it really
matter the small performance difference to justify having two different
methods and not trimming the code base down to one method?

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: making xenstore domain easy configurable

[Andrew Cooper]

On 28/06/16 16:17, Doug Goldstein wrote:
> On 6/28/16 8:59 AM, Andrew Cooper wrote:
>> On 28/06/16 14:36, Juergen Gross wrote:
>>> On 28/06/16 14:42, Andrew Cooper wrote:
>>>> 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.
>>> It is limiting the solution by not allowing me to drop the sockets
>>> completely.
>> I don't think dropping the sockets completely is a sensible course of
>> action.  I had come the conclusion that you were just not going to use
>> them, as opposed to removing them entirely.
>>
>> For xenstored running in the same domain as the toolstack, sockets are
>> less overhead than the shared memory ring, as no hypercalls are
>> involved.  There is also the unfortunate problem that one of the two
>> linux devices for xenstored *still* causes deadlocks when used; a
>> problem which is unresolved from Linux 3.14.
> Since Xen 4.7 the broken devices won't be used by default. I understand
> that the socket interface is faster and less overhead but I guess my
> question is how much data is sent over this interface? Does it really
> matter the small performance difference to justify having two different
> methods and not trimming the code base down to one method?

My gut feeling is that the XenServer bootstorm scalability tests will
notice.  Our metric of "how fast is it to boot 1000 VMs" is very
important for VDI, as employees tend to get to work and try to log
during the same short time period.

~Andrew

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

Re: making xenstore domain easy configurable

[Juergen Gross]

On 28/06/16 17:23, Andrew Cooper wrote:
> On 28/06/16 16:17, Doug Goldstein wrote:
>> On 6/28/16 8:59 AM, Andrew Cooper wrote:
>>> On 28/06/16 14:36, Juergen Gross wrote:
>>>> On 28/06/16 14:42, Andrew Cooper wrote:
>>>>> 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.
>>>> It is limiting the solution by not allowing me to drop the sockets
>>>> completely.
>>> I don't think dropping the sockets completely is a sensible course of
>>> action.  I had come the conclusion that you were just not going to use
>>> them, as opposed to removing them entirely.
>>>
>>> For xenstored running in the same domain as the toolstack, sockets are
>>> less overhead than the shared memory ring, as no hypercalls are
>>> involved.  There is also the unfortunate problem that one of the two
>>> linux devices for xenstored *still* causes deadlocks when used; a
>>> problem which is unresolved from Linux 3.14.
>> Since Xen 4.7 the broken devices won't be used by default. I understand
>> that the socket interface is faster and less overhead but I guess my
>> question is how much data is sent over this interface? Does it really
>> matter the small performance difference to justify having two different
>> methods and not trimming the code base down to one method?
> 
> My gut feeling is that the XenServer bootstorm scalability tests will
> notice.  Our metric of "how fast is it to boot 1000 VMs" is very
> important for VDI, as employees tend to get to work and try to log
> during the same short time period.

I think I'll start with just removing the systemd socket stuff. This is
what I need to make the xenstore domain configurable on the installed
system. Removing of the sockets can be done either later or never.


Juergen


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

Re: making xenstore domain easy configurable

[Jan Beulich]

>>> On 28.06.16 at 15:59, <andrew.cooper3@citrix.com> wrote:
> For xenstored running in the same domain as the toolstack, sockets are
> less overhead than the shared memory ring, as no hypercalls are
> involved.  There is also the unfortunate problem that one of the two
> linux devices for xenstored *still* causes deadlocks when used; a
> problem which is unresolved from Linux 3.14.

And these deadlocks aren't possibly related to the introduction
of FMODE_ATOMIC_POS, and hence would be resolved by
https://patchwork.kernel.org/patch/8752411/(or something along
those lines, if nonseekable_open() isn't used on that code path)?
I ask because we had a similar report, but when I put together the
(refused upstream) patch I assumed the files under /dev wouldn't
have the same issue (and I still didn't check whether they would).

Jan


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

Re: making xenstore domain easy configurable

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 1357 bytes --]

On 6/28/16 11:27 AM, Jan Beulich wrote:
>>>> On 28.06.16 at 15:59, <andrew.cooper3@citrix.com> wrote:
>> For xenstored running in the same domain as the toolstack, sockets are
>> less overhead than the shared memory ring, as no hypercalls are
>> involved.  There is also the unfortunate problem that one of the two
>> linux devices for xenstored *still* causes deadlocks when used; a
>> problem which is unresolved from Linux 3.14.
> 
> And these deadlocks aren't possibly related to the introduction
> of FMODE_ATOMIC_POS, and hence would be resolved by
> https://patchwork.kernel.org/patch/8752411/(or something along
> those lines, if nonseekable_open() isn't used on that code path)?
> I ask because we had a similar report, but when I put together the
> (refused upstream) patch I assumed the files under /dev wouldn't
> have the same issue (and I still didn't check whether they would).
> 
> Jan
> 

They are related to FMODE_ATOMIC_POS. The nodes under /dev don't
experience the same issues. Jonathan Creekmore and I submitted patches
to make /dev/xen/xenbus and /dev/xen/privcmd the preferred interfaces
used by the Xen tools over their /proc/xen/ counterparts in an attempt
to prevent people from being bitten by that. One of the patches made it
into 4.6 and the other didn't make it in until 4.7.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: making xenstore domain easy configurable

[Juergen Gross]

On 28/06/16 14:42, Andrew Cooper wrote:
> 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.

Digging a little bit deeper I think the current xs_restrict()
implementation renders an oxenstore domain completely useless: as
soon as dom0 tries to use xs_restrict() it will loose its privileges
as the complete dom0 connection will be affected. :-(


Juergen

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

Re: making xenstore domain easy configurable

[Andrew Cooper]

On 28/06/16 14:52, Juergen Gross wrote:
> On 28/06/16 14:42, Andrew Cooper wrote:
>> 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.
> Digging a little bit deeper I think the current xs_restrict()
> implementation renders an oxenstore domain completely useless: as
> soon as dom0 tries to use xs_restrict() it will loose its privileges
> as the complete dom0 connection will be affected. :-(

Can't say I am surprised in the slightest.  It is an extension which has
never been used, which invariably means it doesn't work.

(More replies on the other half of this thread, which I am still writing.)

~Andrew

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