[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/5] pciback: new configuration space fields, permissive flag




On 13 Apr 2006, at 14:17, Ryan wrote:

All a user-space policy could then contain is whether a given
field is writable or not (and maybe a mask of exactly which bits are
writable). However, that's probably enough for most devices (although I
can't say for certain having only had a cursory look at the tg3 driver
and no others). I think the header fields and structures on the
capability list will need to remain in kernel-space.

Fair enough. I expect that the fields that need extra processing in pciback will be generic things like power management etc? So really device-specific things (tg3, ide, etc.) simply need at worst bit-wise filtering?

I also wasn't sure when was a good time to inject these rules into the
pciback driver. Right now, the configuration fields get added to a card
when it is probed. I suppose I could generate some kind of hotplug event
to trigger that. Or perhaps some kind of lazy initialization that takes
place through xend the first time that a PCI device is given to a driver
domain.

Doing it lazily makes sense. Management tools must actively bind a PCI device to a new domain, and it makes sense to push down device-specific policy at the same time.

I see your point about the permissive flag. While I think this method is
better than the global flag, I think you're right: we can improve it
more. I could also do a lazy initialization on the permissive flag
(perhaps moving it from a sysfs attribute to xend matching a device id
and setting it in XenStore). Is that more along the lines of what you
were thinking?

Yes, although you could potentially just leave the switch in sysfs. Or do you want to keep it away from direct user interference?

I wouldn't hard-code the permissive device ids in xend. Even something really simple like a single commented text file containing lists of device ids and the appropriate policy (e.g., permissive, or a list of extra config-space fields that can be read and/or written) would be better imo.

Do you have any other comments/concerns about adding the capability list
handlers (like power management) or the bottom-half handler for pci
operations from the frontend?

That all made sense, although I can't say I read the patches in huge detail. It's mainly the wish to avoid hardcoding per-device policy in the kernel that got me worried.

 -- Keir


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.