Re: [Xen-devel] [BUG] Xen vm kernel crash in get_free_entries.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-11-13 at 09:40 +0000, Ian Campbell wrote:
> On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
> > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
> > > > Hello,
> > > > 
> > > > Let me bring some new life to this discussion.
> > > > 
> > > > I've investigated a bit and found another way to make  kernels starting 
> > > > from 3.8.x to boot on the VMs with platform device_id 0002.
> > > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
> > > > patch is not necessary.
> > > > 
> > > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
> > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
> > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
> > > > network are also recognized.
> > > 
> > > I think this is just working around the problem, by avoiding the
> > > situation where the error occurs. You could just as well switch to
> > > platform device id < 2.
> > 
> > I am bit late to this discussion - but shouldn't there be something
> > in the kernel to deal with this?
> 
> Well, ideally the kernel wouldn't crash ;-)
> 
> I don't think it would be appropriate for Linux to bind to the device
> with ID 2, since that has been assigned to a vendor
> http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
> it should be up to them to define the ABI of that device and provide a
> Linux binding if they want.
> 
> Perhaps the unplug protocol
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html needs
> expanding to blacklist products based on the presence absence of
> whichever platform device subids there are.
> 
> I'm a bit confused because I thought the requirement was that the base
> level platform device was always present and the secondary ones (like
> the Citrix PV device with ID 2) would only ever be additional. Maybe I'm
> wrong about that.

It turns out that some of the conclusions in 
http://lists.xen.org/archives/html/xen-devel/2013-11/msg01796.html
are relevant here, especially the subthread from
http://lists.xen.org/archives/html/xen-devel/2013-11/msg01842.html
onwards...

Ian.


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