Re: xenfs aka /proc/xen

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 06/05/2010 09:29 AM, Bastian Blank wrote:
> On Fri, May 28, 2010 at 06:40:02AM +0100, Keir Fraser wrote:
>   
>> On 27/05/2010 23:54, "Bastian Blank" <waldi@debian.org> wrote:
>>     
>>> One of the entries (capabilities) provides information about the
>>> proviledge level to the hypervisor and belongs more likely into
>>> /sys/hypervisor. The four other are plain old devices and belongs into
>>> /dev.
>>>       
> 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).

> * $DEV/xen/xenbus
>   Merge into builtin xenbus support or own module xenbus-user
>   

Would you expect to change the actual ABI/protocol?

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

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?

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

> * 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?

    J