This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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