[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 12:50 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 13 November 2013 12:39
> > To: Paul Durrant
> > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > Subject: Re: Multiple platform PCI device ID registries?
> > 
> > On Wed, 2013-11-13 at 12:30 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 13 November 2013 12:09
> > > > 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:58 +0000, Paul Durrant wrote:
> > > >
> > > > > > 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.
> > > >
> > > > How would you describe it in that document? "Xen PV device (extended
> > > > platform device). Previously used in XenServer 6.1" ?
> > > >
> > > > Is there some spec we can link to regarding how this device should be
> > > > used?
> > 
> > ???
> 
> Sorry, missed that.

You've missed the part about a link to a spec for what the Xen PV device
is, when it should appear, how it relates to the platform device again

> No, it wasn't previously used in 6.1 because it's not really the same
> (as the pv device doesn't implement the fixed IO ports). I also don't
> want to confuse it with the platform device, for that reason. It is a
> new distinct and I agree that the fact it defaults to device ID is
> confusing although it's safe - I will therefore submit a patch to QEMU
> to modify it as I suggested before, so that the id *must* be specified
> by the toolstack.

Ack.

> > 
> > Best bet is to just document "Don't Do That Then". Is there some
> > XenServer way we can tell people to fix this (by changing the ID back?)
> > 
> 
> Well part of the problem is that we don't support use of PVonHVM linux
> in XenServer at all! The best thing is probably to tackle this on the
> XenServer forums if and when someone posts the problem there. Adding
> the extra blacklisting code to XenServer's QEMU and then getting that
> into a hotfix should hopefully avoid future problems too - although we
> may get 'why are my PV frontends not working?'-type questions.

Ah, I see now why it is a XS side fix.

> > I think "no platform device and no pv device" is a valid and useful
> > configuration, meaning "use emulated devices". "no platform device, yes
> > pv device" is the one to avoid.
> > 
> 
> Hmm. How about splitting out the fixed IO ports then? That way the
> platform device could be safely turned off if the PV device was
> present. It seems like a cleaner and safer thing to do.

I thought when the PV device was added it was agreed that it would only
ever be as an extension to the platform device, not a replacement for
it.

Otherwise you get into situations where cloud providers need to know
which to provide, whereas with a baseline platform device always there
things can try and work.

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