From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: xenfs aka /proc/xen Date: Tue, 08 Jun 2010 10:44:06 -0700 Message-ID: <4C0E8166.8080703@goop.org> References: <20100527225440.GC25018@wavehammer.waldi.eu.org> <20100605162947.GA31336@wavehammer.waldi.eu.org> <4C0AF055.1020700@goop.org> <20100606112154.GA8038@wavehammer.waldi.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100606112154.GA8038@wavehammer.waldi.eu.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bastian Blank , Keir Fraser , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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