RE: [Xen-devel] Panic when starting DomU with passthrough

["Han, Weidong" <weidong.han@xxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


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