On 06/06/2010 04:21 AM, Bastian Blank wrote:
> 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.
>
Yes, I've always been a bit disappointed with /sys/hypervisor. I think
it came from the ppc side, and it should be much more useful than it is,
I think. I'm not sure that anybody actually uses it for Xen at the moment.
Also, given that all (? I think there's just one?) the guest
capabilities are Xen specific, as are the other things we're talking
about, there should probably be a xen/ directory to stick all these
things into.
>>> * $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.
>
Well, the kernel already handles all the client-side stuff. The kernel
needn't care much about the content of the data, just provide a
mechanism to shove it over a shared memory ring and provide
notifications, as it does with all the other xen devices.
Also, we have the irritating problem that xenstored is not restartable,
and I think that's partly because there's some limitation about mapping
the shared page or binding the event channel. If the kernel does that
in a device, then it can deal with userspace reopening the device on
restart. (The actual persistance of the data is a separate question.)
>> 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.
>
I don't follow your point here.
> 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]
>
Erm, maybe. I think a plain device is probably a better match though,
and I don't see why there would be much difference in complexity. I
guess the device is rather ioctl-heavy, and having an explicit delimited
format might be nice. But as you mention, the stateless connectionless
property is hard to reconcile with current 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.
>>
> I thought about the capacity of the server part to do damage.
>
The server is pretty inherently trusted in the Xen model, so I don't
think that's a huge concern.
>>> * 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.
>
evtchn and gntdev are usable from domU.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home