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