Re: xsa46-4.2.patch breaks PCI passthrough?

[Andrew Cooper <andrew.cooper3@citrix.com>]

[-- Attachment #1: Type: text/plain, Size: 3046 bytes --]

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@crc.id.au> 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.

Thanks,

~Andrew

[-- Attachment #2: XSA-46-xen-4.2-debug-v3.patch --]
[-- Type: text/plain, Size: 690 bytes --]

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index b3bfb38..be30cf3 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -908,6 +908,16 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         else
             ret = pirq_deny_access(d, pirq);
 
+        printk("**DBG perms { %u, %d } = %ld\n", pirq, allow, ret);
+        if ( ret )
+        {
+            printk(" Domain %"PRId16", nr_pirqs %d\n",
+                   d->domain_id, d->nr_pirqs);
+            printk(" dom_pirq_to_irq(%d) = %d\n",
+                   pirq, domain_pirq_to_irq(d, pirq));
+            rangeset_domain_printk(d);
+        }
+
         rcu_unlock_domain(d);
     }
     break;

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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