Xen devel - Jul 2006 - [PATCH 4/5] pciback: user-space quirks policy

The attached patch contains two policy files written in what is intended
to be human-readable SXP.

1. xend-pci-quirks.sxp:

Specifies which PCI device(s) may write to a set of PCI configuration
space registers.  A quirky PCI device is identified by its vendor ID,
device ID, subvendor ID, and subdevice ID.  If a matching entry is
found, the corresponding fields will be sent to the PCI bus manager.
Fields are composed of a register, size, and mask -- although the mask
field is currently unused.

The included policy file is for a range of tg3 devices, which is the
only type of quirky device I know about.  Users with other quirky
devices are invited to either add entries to this policy file or add an
entry in the permissive file, described next.  In either case, send an
email to the xen-devel list to make the device known.

2. xend-pci-permissive.sxp

Lists PCI devices that pciback should not prevent from writing to their
configuration space.  This can be necessary if, for example, a new
Tigon3 devices is released with different PCI vendor/device values such
that no entry in xend-pci-quirks.sxp is triggered.

Signed-off-by: Chris Bookholt <hap10@tycho.ncsc.mil>


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

On 17 Jul 2006, at 20:15, Chris wrote:
> The attached patch contains two policy files written in what is 
> intended
> to be human-readable SXP.
A few comments on the format:

  1. Instead of having xend-pci-permissive.sxp empty, could you:
(unconstrained_dev_ids
    (
         # ''XXXX:XX:XX.X''
    )
)
     This would simplify the header comment as no need to have separate 
explanation for empty file.

  2. It''s a bit weird that xend-pci-quirks.sxp identifies devices by 
vendor/device ids, but xend-pci-permissive.sxp identifies by slot. 
Could the latter also identify by vendor/device ids -- after all, the 
need to be in the list is a property of the device, not its position on 
the PCI bus. This would also allow us to add devices to this list in a 
way that''s portable across systems (an idea I''m sure you hate
;-).

  3. Can we define the identifier format as 
<vendor>:<device>[:<subvendor>:<subdevice>]. The
sub-details ffff:ffff
crop up rather a lot and it''d be neater to be able to make that a 
default if that section of the identifier string isn''t present.

Apart from that, as far as I can tell you parse the config files 
whenever a PCI device is bound to a domain. You pick out matching 
entries and poke them down to pciback via sysfs. All seems sensibel to 
me. Is there a way of reading out from sysfs the quirks and ''permissive
status'' for a particular device (or all devices)? That could be handy.

  Thanks!
  Keir


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

Keir Fraser wrote:
>  1. Instead of having xend-pci-permissive.sxp empty, could you:
> (unconstrained_dev_ids
>    (
>         # ''XXXX:XX:XX.X''
>    )
> )
>     This would simplify the header comment as no need to have separate
> explanation for empty file.
Agreed; done.
>  2. It''s a bit weird that xend-pci-quirks.sxp identifies devices
by
> vendor/device ids, but xend-pci-permissive.sxp identifies by slot. Could
> the latter also identify by vendor/device ids -- after all, the need to
> be in the list is a property of the device, not its position on the PCI
> bus. This would also allow us to add devices to this list in a way
> that''s portable across systems (an idea I''m sure you hate
;-).
There was a method to my madness.  The goal was to make using devices
that require permissive mode possible, but to discourage its use as a
long-term solution, thereby encouraging admins to feed their quirky
device info back to xen-devel for a proper fix in xend-pci-permissive.sxp.

However, since my argument against your suggestion is more philosophical
than technical I''m willing to compromise; done
>  3. Can we define the identifier format as
> <vendor>:<device>[:<subvendor>:<subdevice>]. The
sub-details ffff:ffff
> crop up rather a lot and it''d be neater to be able to make that a
> default if that section of the identifier string isn''t present.
Seems reasonable; done.
> Is there a way of reading out from sysfs the quirks and
''permissive
> status'' for a particular device (or all devices)? That could be
handy.
The documentation was lacking in this area, but this feature was already
there.  Doing a cat on /sys/bus/pci/drivers/pciback/permissive will list
devices currently in permissive mode.  Similarly, cat''ing
/sys/bus/pci/drivers/pciback/quirks will show each device bound to the
PCI backend and any quirks it is afforded.  Relevant sections have been
added to the users guide to document these features.

A note of interest: a standard set of 17 quirks is applied to all PCI
devices when they are bound to pciback.  The rest of the device-specific
quirks get added by xend via sysfs when a device is bound to a domain.

See attached patches that include the requested changes.

Three are changed from the original submission:
	- pciback-uspace-quirks-xend.patch
	- pciback-uspace-quirks-policy.patch
	- pciback-uspace-quirks-doc.patch

The other two are the same as before:
	- pciback-uspace-quirks-linux.patch
	- pciback-per-device-permissive-flags.patch

The order of patch application remains the same.

-Chris






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

On 27 Jul 2006, at 13:56, Chris wrote:
>>  2. It''s a bit weird that xend-pci-quirks.sxp identifies
devices by
>> vendor/device ids, but xend-pci-permissive.sxp identifies by slot. 
>> Could
>> the latter also identify by vendor/device ids -- after all, the need 
>> to
>> be in the list is a property of the device, not its position on the 
>> PCI
>> bus. This would also allow us to add devices to this list in a way
>> that''s portable across systems (an idea I''m sure you
hate ;-).
>
> There was a method to my madness.  The goal was to make using devices
> that require permissive mode possible, but to discourage its use as a
> long-term solution, thereby encouraging admins to feed their quirky
> device info back to xen-devel for a proper fix in 
> xend-pci-permissive.sxp.
Yes, that was my suspicion. :-)  Not unreasonable really as it 
shouldn''t be hard to work out a quirks list for any given device, but 
I''d rather keep the same method of device identification across both 
config files.

By the way, your email didn''t contain attachments but had a humungous 
blob of patch appended instead. Could you resend (all in one email is 
fine, but separate attachments) and remind me of the order in which to 
apply them? Thanks!

  -- Keir


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