Re: [Xen-devel] xenfs aka /proc/xen

[Bastian Blank <waldi@xxxxxxxxxx>]

On Sat, Jun 05, 2010 at 05:48:21PM -0700, Jeremy Fitzhardinge wrote:
> On 06/05/2010 09:29 AM, Bastian Blank wrote:
> > Okay. I thought about it and would settle for the following:
> > * $SYSFS/hypervisor/properties/guest_capabilites
> >   It includes the same value then $XENFS/capabilities. Or should that be
> >   changed as the meaning of "control_d" is not really clear (like
> >   "control-domain")?
> The general rule for sysfs is one value per file.  It would probably be
> more consistent to have a (guest_)capabilities directory, with a file
> per capability (containing 1/0, or some other value if appropriate).

You are right. However, the current sys/hypervisor interface already
uses multi-valued items.

> > * $DEV/xen/xenbus
> >   Merge into builtin xenbus support or own module xenbus-user
> Would you expect to change the actual ABI/protocol?

To reduce the complexity, partial messages could be disallowed.

> > * $DEV/xen/privcmd
> >   - Module xen-control or so
> >   - *Needs to check for CAP_ADMIN*
> > * $DEV/xen/xenstored
> >   - Module xen-control or so
> >   - Merges xsd_kva and xsd_port
> >   - Supports:
> >     - mmap, only support pagesized maps
> >     - ioctl: get event channel port, get size (page size may be different)
> Yes, the interface of exposing the xenstore mfn to userspace has always
> seemed a bit mad.  The kernel driver should do the mapping for
> usermode.  Does it also need to expose the xs event channel?  Or can the
> kernel just handle it internally and expose a normal blocking interface.

Sure, it can. However it moves the complexity from the userspace into
the kernel. As there are only two users right now, I doubt that the
easier userspace implementations would outweigh the possible problems.

> In fact, does it needs its own separate driver?  This is just
> symmetrical with /{proc,dev}/xen/xenbus.  Can that driver be made to
> handle both ends?  Or at least a driver which looks symmetric to the
> guest-side xenbus?

Not sure if this is worth the problems: Only one access-control path for
both client and server access.

However, if you want to go this way, I would propose a different
solution that looks the same in all the different access paths from
userspace: Netlink. This is than a complete overhaul.[1]

> >   - Security constraints needs check. What can a user with access to
> >     this device do?
> Policy should be enforced by xenstored itself.  Guests are not
> trustworthy in general, so there's no point in enforcing anything within
> the guest kernel.

I thought about the capacity of the server part to do damage.

> > * Core kernel may trigger loading of xen-control module by some means
> >   (to be defined).
> All a bit awkward, since there's no obvious trigger to hang the load
> event off.  Maybe key them off Xen or xenbus bringup as some kind of
> adjunct pseudo device?

Yeah. Something like that. Maybe just use the control domain capability
in the sys/hypervisor tree for that. The uevent response can set
MODALIAS.

Bastian

[1]: The problem is that this interface would be completely asynchron
with no notion of a statefull connection. However it would be a large
reduction in complexity and state.

Currently xenstore supports three types of messages: Transactional,
Read/Write and Watch. Transactional commands would go away. Every
message woule be its own transaction as such a protocol can not handle
long running transactions (are they really needed anyway?). Read/Write
would just work. Watch would be replaced by relayed change requests like
udev uses to acknowledge its work finished on an event.

-- 
Klingon phaser attack from front!!!!!
100% Damage to life support!!!!

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel