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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-11-05 at 12:45 +0000, Andrew Cooper wrote:
> On 05/11/14 12:39, Ian Campbell wrote:
> > On Wed, 2014-11-05 at 13:01 +0100, Atom2 wrote:
> >
> > Thanks for all that, sadly it's not giving me any clues what is going
> > wrong :-/
> >
> >> To me, it looks as if something is broken with the PCI passthrough stuff 
> >> and that has started with 4.3.3. Strangely however, valgrind seems to 
> >> work around that issue insofar that no segfault happens. Is there any 
> >> explanation of the different behaviour between native execution of xl 
> >> and starting xl under valgrind's control?
> > Valgrind has it's own memory allocator etc, but it's supposed to catch
> > errors, not hide them. I think even 3.10.0 is missing support for some
> > hypercalls which are being used by passthrough, which is why we are
> > continuing to see different behaviours.
> >
> > I think we are reaching the point of diminishing returns with vagrind.
> > It probably is worth rerunning with "-v --leak-check=full", but after
> > that we'd be looking at adding valgrind patches for the new hypercalls,
> > which I don't think will be worthwhile (although I intend to write the
> > patches anyway).
> >
> > So unless "-v --leak-check=full" tells me something (which I'm doubtful
> > of at this stage) I think we're back to bisecting the changes since
> > 4.3.1, sorry.
> 
> The lack valgrind support for XEN_DOMCTL_test_assign is causing PCI
> Passthrough to fail.
> 
> This is where "libxl: error: libxl_pci.c:1045:libxl__device_pci_add: PCI
> device 0000:0a:0b.0 cannot be assigned - no IOMMU?" comes from.
> 
> While I do have 10 patches I really should get around to upstreaming
> into valgrind, the passthrough hypercalls are not amongst them.  Fixing
> XEN_DOMCTL_test_assign is only the first step.

I've just written (but not tested) that one.

Ian.


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