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

To: Ryan <hap9@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/5] pciback: new configuration space fields, permissive flag
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 13 Apr 2006 10:06:11 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 13 Apr 2006 02:05:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1144780315.24874.66.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1144780315.24874.66.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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