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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell
> Sent: 13 November 2013 11:44
> 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: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?
> 

Yes.

> 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.
> 

I believe it is safe.

> >  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?
> 

I guess we could default the prop to something like 0xffff and then fail the 
init fn if we find the value unmodified. Would that be better?

> 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.
> 

As I understood it, that problem is slightly distinct. It's a case of someone 
bringing up HVM linux in a XenServer VM and then getting a crash because 
PVonHVM doesn't set up properly due to the change in device_id for the 
*platform* device. Using device ID to for the PV device should not cause such 
fallout as the platform device is left unmolested.

> 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?
> 

That should not be necessary as the point of registering the devid is that 
on-one else creates driver that bind to that devid. Certainly no-one has to 
date.

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