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

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



> -----Original Message-----
> From: Ian Campbell
> Sent: 13 November 2013 13:27
> To: Paul Durrant
> Cc: xen-devel; Ian Jackson; Stefano Stabellini
> Subject: Re: Multiple platform PCI device ID registries?
> 
> On Wed, 2013-11-13 at 13:25 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 13 November 2013 13:14
> > > 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: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
> >
> > Oh sorry - too many emails in different threads... No, there is no
> > spec. in existence. The xl.cfg manpage refers readers to
> > pci-device-reservations.txt so I guess that would be the best place to
> > add some words.
> 
> Do you think you could do that? I'm clearly to confused to write
> anything useful...
> 

Ok. Will do. Just doing the QEMU things first.

> >
> > >
> > > > 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.
> > >
> >
> > Yes, agreed, it is intended as an extra device but the fact that
> > removing the *PCI* platform device from the VM disables the fixed IO
> > ports is somewhat counter-intuitive so I was proposing that should be
> > fixed. Then *if* someone had the PV device and removed the platform
> > device any bound PV frontends would continue to function.
> 
> If someone removes the platform device then this should cause the PV
> device to be removed or for configurations which specify PV but not
> platform device to be rejected.
> 

Ok then. That's what will happen today so I'll mention it in the doc.

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