Re: [BUG] XEN 4.3.3 - segfault in xl create for HVM with PCI passthrough

[Ian Campbell <Ian.Campbell@citrix.com>]

On Tue, 2014-11-04 at 17:48 +0100, Atom2 wrote:
> Am 04.11.14 um 17:31 schrieb Ian Campbell:
> > On Tue, 2014-11-04 at 17:14 +0100, Atom2 wrote:
> >> Am 04.11.14 um 16:44 schrieb Ian Campbell:
> >>> On Tue, 2014-11-04 at 16:13 +0100, Atom2 wrote:
> >>> Otherwise I think the next step would be to downgrade to 4.3.1 and see
> >>> if the problem persists, in order to rule out changes elsewhere in the
> >>> system. If the problem doesn't happen with a 4.3.1 rebuilt on your
> >>> current system then the next thing would probably be to bisect the
> >>> issue. There are only 31 toolstack changes in that range, so it ought to
> >>> only take 5-6 iterations.
> >> Unfortunately 4.3.1 is no longer available as an ebuild as 4.3.3 seemed
> >> to fix security issues and therefore 4.3.1 has been deleted from the
> >> repos. So it's not straightforward and I need to figure out how to get
> >> the old version back. But I am sure there's a way.
> >
> > I don't know anything about ebuilds, but if you end up needing to bisect
> > then building from xen.git might be useful anyway (unless you can get an
> > ebuild to trivially build some other version).
> Before I go down that route would I also need to re-compile xen (i.e. 
> the hypervisor at /boot/xen-4.3.3.gz that's being booted from grub) or 
> only xen-tools? In other words does xen-tools 4.3.1 work with the 
> hypervisor version 4.3.3 under /boot?

I think in principal within a stable branch (i.e. 4.3.x) it ought to
work, but I wouldn't swear to it. I think you can probably risk it --
the failure mode in case of a bad mismatch will be very different (liek
a permissions failure early in building a domU), so if you see anything
newly odd you could rebuild Xen.

> I wouldn't want to end up with an unbootable system.

A tools/hv mismatch won't ever stop dom0 booting, it would just stop you
starting a guest. You can always boot the kernel natively in any case.

> In terms of ebuilds: Adding patches to a version is pretty easy as 
> gentoo works from source code. So if 4.3.3 is just different by a number 
> of well defined patches from 4.3.1 then that should be straightforward 
> as applying patches is really trivial.

The git history from 4.3.1 to 4.3.3 is (as it happens) completely
linear, so something like git format patch should trivially produce a
list of patches to apply (or perhaps unapply if it is easier to work
backwards from 4.3.3). I don't know what local patches the ebuild
includes or how much conflict there will be though.

Ian.