Re: [Xen-devel] xsa46-4.2.patch breaks PCI passthrough?

[Steven Haigh <netwiz@xxxxxxxxx>]

On 05/05/2013 03:23 AM, Andrew Cooper wrote:
> On 03/05/2013 23:15, Steven Haigh wrote:
> > On 05/02/2013 02:07 AM, Andrew Cooper wrote:
> > > On 01/05/13 16:26, Steven Haigh wrote:
> > > > On 2/05/2013 1:18 AM, George Dunlap wrote:
> > > > > On Wed, May 1, 2013 at 6:29 AM, Steven Haigh <netwiz@xxxxxxxxx> wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > I've had a report lodged against my packages that the patch provided for
> > > > > > XSA46 against Xen 4.2.1 causes PCI passthru to break.
> > > > > >
> > > > > > It seems that 4.2.1 *without* the XSA46 patch works perfectly. 4.2.2 does
> > > > > > not work.
> > > > > Have you tried this with xen-unstable tip?  That would be a blocker
> > > > > bug for the 4.3 release.
> > > > Hi George,
> > > >
> > > > It hasn't been tried it against anything other than 4.2.1 & 4.2.2 as
> > > > yet. As I'm not the end user with the problem here, I need to wait for
> > > > feedback.
> > > >
> > > > I have passed the patch provided by Andrew to the bug author - when I've
> > > > got feedback on this I'll be able to provide more information. I think
> > > > when we've got a root cause for this then it should be simple to verify
> > > > it on 4.3.
> > > I have been investigating this issue on XenServer.
> > >
> > > On XenServer, PCIPassthrough to a SLES11SP1 guest is working correctly,
> > > even with the XSA-46 patch applied.
> > >
> > > When passing through physical devices, my hypervisor debugging is being
> > > triggered, but the actions of XEN_DOMCTL_irq_permission appear to be
> > > correct, given sensible input from the Xapi toolstack.  When passing
> > > through an SRIOV virtual function, no hypervisor debugging is being
> > > triggered.
> > >
> > > At a preliminary guess, I would say that XM looks to be doing something
> > > stupid which it used to be getting away with, but is not now given the
> > > changed in the hypervisor.
> > >
> > > I suspect that it will be hard to progress this issue until Gordan
> > > applied my debugging patch and gets back with the results.
> > Hi Andrew,
> >
> > Got a reply from Gordon -> http://xen.crc.id.au/bugs/view.php?id=5
> >
> > The 'xm dmesg' output shows the following:
> > (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of mfn
> > 4bc435: c=c000000000000002 t=7400000000000001
> > (XEN) **DBG perms { 16, 1 } = 0
> > (XEN) **DBG perms { 34, 1 } = -22
> > (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of mfn
> > 4be230: c=c000000000000002 t=7400000000000001
> > (XEN) **DBG perms { 16, 1 } = 0
> > (XEN) **DBG perms { 34, 1 } = -22
> >
> > The full dmesg is attached to the bug report.
> >
> > --
> > Steven Haigh
> Unrelated to the PCI passthrough problem, those spurious sh errors are
> fixed by
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=0984c2b63a7c3e9dfa770b29dac51a5124aecaab
>
>  From Gordon's log, it appears pirq 34 is the one causing problems.
>
> Can he please try the latest attached debugging patch which should
> provide rather more information in the failure case.
>
> Also, can he boot with "loglvl=all" on the Xen command line, and also
> issue "xm debug-keys izq" before capturing xm dmesg.  The debug keys
> should dump loads on information into the dmesg buffer to do with
> interrupts etc.
Debug log is now attached to the bug report. Its a little large to 
attach here.
http://xen.crc.id.au/bugs/file_download.php?file_id=13&type=bug

--
Steven Haigh

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