Xen devel - Feb 2009 - Panic when starting DomU with passthrough

Hi all,

I''m getting panic errors when doing passthrough. The attached log
occurs when I start DomU with passthrough on 00:02.0. Anybody else
getting this?

Thanks.

-Alex


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

I presume that 00:02.0 is the graphics card you mentioned in your
earlier mail?  Could you do an lspci on the device in question (''lspci
-vv -s 0:2.0'').  Is the dumU a PV or a HVM guest?  If it is a PV
guest, is iommu=pv enabled or not?

Looks like the device is trying to write to ''fffff000'' which
seems
like a bit of an odd address to be accessing.

Anyhow, even if the accesses of the device seem a bit mad it still
should not be able to access random xen internal memory.  I can''t see
any good reason why the assertion should be triggered.  Could you
perhaps apply the patch below to give us some more clue as to what is
happening?

Keir, could this assertion possibly be related to the recent IRQ
acktype changes?

     eSk



--
diff -r 02a8093f6bfd xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c        Thu Feb 19 11:34:10 2009 +0000
+++ b/xen/arch/x86/irq.c        Thu Feb 19 12:17:55 2009 +0000
@@ -319,6 +319,9 @@ static void __do_IRQ_guest(int vector)
     if ( action->ack_type == ACKTYPE_EOI )
     {
         sp = pending_eoi_sp(peoi);
+        if ( !((sp == 0) || (peoi[sp-1].vector < vector)) )
+            printk("sp = %d, peoi[sp-1].vector = %d, vector = %d\n",
+                   sp, peoi[sp-1].vector, vector);
         ASSERT((sp == 0) || (peoi[sp-1].vector < vector));
         ASSERT(sp < (NR_VECTORS-1));
         peoi[sp].vector = vector;


[Alexia Benington]
> Hi all,
> I''m getting panic errors when doing passthrough. The attached log
> occurs when I start DomU with passthrough on 00:02.0. Anybody else
> getting this?

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

Hi,

If you were referring to the mail "iommu hangs boot", then yes,
I''m
referring to the integrated Intel gfx, which I managed to get
passthrough to work, briefly, before this happened. I never got the
ATI gfx to work, although somehow it needs to be present for Dom0 to
even boot correctly. But I think these are two different issues.

The lspci output is in "090219.2.log". It''s a HVM guest.

This is the output after the patch: sp = 1, peoi[sp-1].vector = 184,
vector = 184
The complete log is in "090219.1.log".

Thanks.

-Alex

On Thu, Feb 19, 2009 at 9:04 AM, Espen Skoglund
<espen.skoglund@netronome.com> wrote:
> I presume that 00:02.0 is the graphics card you mentioned in your
> earlier mail?  Could you do an lspci on the device in question
(''lspci
> -vv -s 0:2.0'').  Is the dumU a PV or a HVM guest?  If it is a PV
> guest, is iommu=pv enabled or not?
>
> Looks like the device is trying to write to ''fffff000''
which seems
> like a bit of an odd address to be accessing.
>
> Anyhow, even if the accesses of the device seem a bit mad it still
> should not be able to access random xen internal memory.  I can''t
see
> any good reason why the assertion should be triggered.  Could you
> perhaps apply the patch below to give us some more clue as to what is
> happening?
>
> Keir, could this assertion possibly be related to the recent IRQ
> acktype changes?
>
>     eSk
>


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

Hi all,

This doesn''t seem to be going anywhere. Has anyone encountered this
before? Why would it try to write to 7e000000 with Reason 2, followed
by 7d000000 with Reason 5? Note that this differs from my first post
where it tries to write to fffff000.

What does the numbers represent for the various reasons? Is the
interrupt request triggered due to the series of illegal writes?

Thanks and have a good weekend.

-Alex

On Thu, Feb 19, 2009 at 9:37 AM, Alexia Benington
<alexbenington@gmail.com> wrote:
> Hi,
>
> If you were referring to the mail "iommu hangs boot", then yes,
I''m
> referring to the integrated Intel gfx, which I managed to get
> passthrough to work, briefly, before this happened. I never got the
> ATI gfx to work, although somehow it needs to be present for Dom0 to
> even boot correctly. But I think these are two different issues.
>
> The lspci output is in "090219.2.log". It''s a HVM guest.
>
> This is the output after the patch: sp = 1, peoi[sp-1].vector = 184,
> vector = 184
> The complete log is in "090219.1.log".
>
> Thanks.
>
> -Alex
>
> On Thu, Feb 19, 2009 at 9:04 AM, Espen Skoglund
> <espen.skoglund@netronome.com> wrote:
>> I presume that 00:02.0 is the graphics card you mentioned in your
>> earlier mail?  Could you do an lspci on the device in question
(''lspci
>> -vv -s 0:2.0'').  Is the dumU a PV or a HVM guest?  If it is a
PV
>> guest, is iommu=pv enabled or not?
>>
>> Looks like the device is trying to write to
''fffff000'' which seems
>> like a bit of an odd address to be accessing.
>>
>> Anyhow, even if the accesses of the device seem a bit mad it still
>> should not be able to access random xen internal memory.  I
can''t see
>> any good reason why the assertion should be triggered.  Could you
>> perhaps apply the patch below to give us some more clue as to what is
>> happening?
>>
>> Keir, could this assertion possibly be related to the recent IRQ
>> acktype changes?
>>
>>     eSk
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Alexia Benington wrote:
> Hi all,
> 
> This doesn''t seem to be going anywhere. Has anyone encountered
this
> before? Why would it try to write to 7e000000 with Reason 2, followed
> by 7d000000 with Reason 5? Note that this differs from my first post
> where it tries to write to fffff000.
> 
Reason 2 means "The Present (P) field in the context-entry used to process
the DMA request is Clear." That is to say the context mapping was not done
for 00:02.0.
Reason 5 means "The Write (W) field in a page-table entry used for address
translation of a write request or AtomicOp request is Clear." That is to
say context mapping was done for 00:02.0, but the address was not mapped in VT-d
page table.

Current Xen unstable doesn''t support graphics assignment. There are
many tricks on graphic assignment. Can you try to assign a NIC to guest with
VT-d? Let''s to say if this issue still exist or not.

Regards,
Weidong
> What does the numbers represent for the various reasons? Is the
> interrupt request triggered due to the series of illegal writes?
> 
> Thanks and have a good weekend.
> 
> -Alex
> 
> On Thu, Feb 19, 2009 at 9:37 AM, Alexia Benington
> <alexbenington@gmail.com> wrote:
>> Hi,
>> 
>> If you were referring to the mail "iommu hangs boot", then
yes, I''m
>> referring to the integrated Intel gfx, which I managed to get
>> passthrough to work, briefly, before this happened. I never got the
>> ATI gfx to work, although somehow it needs to be present for Dom0 to
>> even boot correctly. But I think these are two different issues.
>> 
>> The lspci output is in "090219.2.log". It''s a HVM
guest.
>> 
>> This is the output after the patch: sp = 1, peoi[sp-1].vector = 184,
>> vector = 184 The complete log is in "090219.1.log".
>> 
>> Thanks.
>> 
>> -Alex
>> 
>> On Thu, Feb 19, 2009 at 9:04 AM, Espen Skoglund
>> <espen.skoglund@netronome.com> wrote:
>>> I presume that 00:02.0 is the graphics card you mentioned in your
>>> earlier mail?  Could you do an lspci on the device in question
>>> (''lspci -vv -s 0:2.0'').  Is the dumU a PV or a
HVM guest?  If it is
>>> a PV guest, is iommu=pv enabled or not?
>>> 
>>> Looks like the device is trying to write to
''fffff000'' which seems
>>> like a bit of an odd address to be accessing.
>>> 
>>> Anyhow, even if the accesses of the device seem a bit mad it still
>>> should not be able to access random xen internal memory.  I
can''t
>>> see any good reason why the assertion should be triggered.  Could
>>> you perhaps apply the patch below to give us some more clue as to
>>> what is happening? 
>>> 
>>> Keir, could this assertion possibly be related to the recent IRQ
>>> acktype changes? 
>>> 
>>>     eSk
>>> 
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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