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
|
Home