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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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