| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH 0/5] pciback: new configuration space fields, per
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
|
|
|
| |
|
Home