Re: [Xen-devel] Re: Comments on Xen bug 1732

[Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>]

On Thu, 2011-03-17 at 07:48 +0000, Jan Beulich wrote:
> >>> On 16.03.11 at 14:50, Gianni Tedesco <gianni.tedesco@xxxxxxxxxx> wrote:
> > On Wed, 2011-03-16 at 08:22 +0000, Jan Beulich wrote:
> >> >>> On 15.03.11 at 19:30, Gianni Tedesco <gianni.tedesco@xxxxxxxxxx> wrote:
> >> > Furthermore this used to work on xen 3.4 but fails on 4.1 so it seems to
> >> > be a regression. One other notable change is the assignments of the
> >> > MSI-X vectors that I see when hitting the Q debug key:
> >> > 
> >> > On 3.4:
> >> > (XEN) 04:10.0 - dom 1   - MSIs < 66 74 82 >
> >> > 
> >> > On 4.1:
> >> > (XEN) 04:10.1 - dom 0   - MSIs < 117 118 119 >
> >> 
> >> dom 1 on 3.4 vs dom 0 on 4.1? And different functions? Doesn't
> >> look like a 1:1 comparison to me.
> > 
> > Yeah they are different machines with the same SR-IOV NIC (similar
> > enough hardware wise). But the point is the different assigned domains,
> > bear in mind that in both cases the function in question is assigned to
> > a guest at the time the debug key was pressed.
> 
> And even iommu=verbose doesn't produce anything more
> informative? Something must be going wrong during the
> assignment...

Just a bunch of stuff like this:
(XEN) [VT-D]iommu.c:1363: d0:PCIe: map bdf = c:10.1
(XEN) PCI add Virtual Function 0c:10.1

> Are the kernels in host and guest exactly the same in both the
> 3.4 and the 4.1 cases? Using pciback or pci-stub?

Well I am currently working on getting a repro on two identical boxes
differing only by hypervisor versions, will let you know.

> >> > Any ideas?
> >> 
> >> Not really. Despite me not thinking that the change in question
> >> (that introduced the WARN_ON()s) has any functionality impact
> >> (it's really only about trying to write protect certain MMIO
> >> ranges, with the WARN_ON()s reporting that this didn't work as
> >> expected) - did you try reverting it (and its follow-up fixes)?
> > 
> > No change.
> 
> With that, the regression then clearly must be elsewhere, and
> I'm afraid we're having to hope that Intel folks will take a look.

*nods*

Gianni


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel