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 Thu, 2006-04-13 at 14:45 +0100, Keir Fraser wrote:
> 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?

That's probably correct. The generic things like power management and
the header registers should be the only things that need to call the
kernel's pci functions (on a side note, I don't know how useful the
power management stuff is right now, but it was intended as more of an
example for how other capability list structures might be handled; in
particular, I thought that someday when MSI is supported in Xen, perhaps
the driver domain's interface for setting up MSI for a device could
happen through these virtual configuration space fields (although I'm
not familiar enough with MSI to know if that is feasible or not)). A
quick glance through the kernel at other drivers that use
device-specific fields leads me to believe that this will be enough (I
suppose it would be better to wait and revisit this if someone ever
finds a device/driver that demonstrates that it's not enough).

> 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.

Is it appropriate for xend to read/write a configuration file? xend's
clients (xm) are the ones that do the processing of config. files now
and I wasn't sure if it was acceptable to have xend reach into a
configuration file (say /etc/xen/pci_permissive_ids.conf). I believe it
must happen on xend, but if it's not hard-coded in, what would be the
appropriate place to read the config file from?

> > 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.

I understand and agree. I'll fix them and resubmit.


Xen-devel mailing list