| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
Ryan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home