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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 11 Apr 2006, at 19:31, Ryan wrote:

> The following patches add some new capabilities to the PCI Backend's
> virtual configuration space handler (such as support for the tg3 
> network
> card and for the Vital Product Data and Power Management structures on
> the capability list). These patches must be applied together (I've 
> tried
> to divide them up into logical groups of functionality for easier
> review, but there is a bit of overlap).
>
> These patches also contain some general formatting fixes and renaming 
> of
> a few functions to clarify their purpose in light of the new code.
It seems to me that this splits policy decisions on permissiveness of 
access to a particular PCI device between user space and kernel. 
Specifically, to make good automatic use of the per-device permissive 
flag we will need a mapping in user space from device ids to correct 
setting of the flag. If you leave it manually to the user, you know 
which way it will always be set. :-) At the same time, in the kernel we 
have a mapping from device ids to filtering rules, which are just 
another facet of filtering policy.
I think it would be much neater to implement only the enforcement 
mechanisms in the kernel driver, and to move all the rules about which 
registers may be accessed for which device types out into user space. 
Then, when binding a PCI device to pciback we would also squirt the 
filtering rules into the kernel. This seems to me preferable for a 
number of reasons:
 1. We don't end up with a scaling mess of extra C source files for 
every new device we come across.
 2. Maintain the rules in an easier to edit format in text files
 3. One place we maintain mappings from device ids -> filtering policies

The main downside is the extra work to push the rules into the kernel 
and do whatever parsing is required. It does feel like the right way to 
go, though.
 -- Keir



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