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

[Ryan <hap9@xxxxxxxxxxxxxx>]

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.

Ryan


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