[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Multiple platform PCI device ID registries?



On Wed, 2013-11-13 at 11:33 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 13 November 2013 11:25
> > To: Paul Durrant
> > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > Subject: Re: Multiple platform PCI device ID registries?
> > 
> > On Wed, 2013-11-13 at 11:01 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 13 November 2013 09:41
> > > > To: xen-devel
> > > > Cc: Paul Durrant; Ian Jackson; Stefano Stabellini
> > > > Subject: Multiple platform PCI device ID registries?
> > > >
> > > > http://xenbits.xen.org/docs/unstable-staging/misc/pci-device-
> > > > reservations.txt
> > > > vs
> > > > http://xenbits.xen.org/docs/unstable-
> > > > staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
> > > >
> > > > Are they distinct namespaces? Can someone clarify with a patch to one or
> > > > both what the relationship is? How does this relate to the additional
> > > > platform device thing which Paul added to qemu?
> > > >
> > > > I'm particularly concerned that 0x0002 is different in the two of
> > > > them...
> > > >
> > >
> > > They are distinct namespaces. The former is PCI device ID, the latter
> > > is an abstract 'product number' which is used as part of the QEMU
> > > unplug protocol (and actually means nothing to the upstream QEMU
> > > platform device code anyway).
> > 
> > I'm confused then. qemu.git:
> >         commit 8fbab3b62a271526c782110aed0ae160eb38c296
> >         Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
> >         Date:   Mon Jul 29 10:58:01 2013 +0000
> > 
> >             Xen PV Device
> > 
> >             Introduces a new Xen PV PCI device which will act as a binding 
> > point for
> >             PV drivers for Xen.
> >             The device has parameterized vendor-id, device-id and revision 
> > to
> > allow to
> >             be configured as a binding point for any vendor's PV drivers.
> > 
> >             Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> >             Signed-off-by: Stefano Stabellini 
> > <stefano.stabellini@xxxxxxxxxxxxx>
> >             Reviewed-by: Andreas FÃrber <afaerber@xxxxxxx>
> > 
> > Adds a new device with parameterized vendor and device-id, which sounds
> > like a pci-device-reservations.txt thing. But you reserved entries in
> > the pvdrivers.h list which is a "product number" thing? Maybe I'm
> > confusing two different events?
> > 
> 
> Yes, they are completely distinct things. Not related in the slightest.

OK!

> The former was to add a parameterized device which we can use to hang
> PV drivers off for Windows Update purposes.
> The latter was add reservations for a product numbers that is already
> in use in XenServer, and another one which we will use going forward
> that - by reserving it - should now not conflict with anyone else's PV
> drivers in future (if anyone cares to add product-number-based
> blacklisting into upstream QEMU or amend the code in trad.)
> 
> > That patch uses device ID
> > #define PCI_DEVICE_ID_XEN_PVDEVICE       0x0002
> > 
> > which appears to conflict with pci-device-reservations.txt which says
> > that devid 2 is "Citrix XenServer (grandfathered allocation for
> > XenServer 6.1)" Or maybe the comment there is just out of date?
> > 
> 
> Using 2 seems safe as it doesn't conflict with the platform device ID
> and we have now registered that ID.

You are referring to the registration in pci-device-reservations.txt,
right?

I'm concerned because that comment refers to XenServer 6.1 but it now
appears to be being reused as the default device ID for the "Xen
pvdevice".

Maybe it is safe to reuse this in this way, but the docs should be
updated I think.

>  In practice it should never be used as the device ID should always be
> specified by the toolstack.

But it defaults to the Citrix ID -- is that wise? Wouldn't it be better
to default to nothing?

It also seems to be causing a moderate amount of fallout in the
"[Xen-devel] [BUG] Xen vm kernel crash in get_free_entries." thread.

I'm busy wondering if maybe Qemu should blacklist non-xenserver product
ids when it has been configured with the Xen PV device using the Citrix
devid?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.