Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.09.12 at 18:43, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
>> Did you also update xen tools accordingly? Sometime I also saw a few 
>> IO_PAGE_FAULTs came from nic if my tools version and HV version did not 
>> match. But using recent 4.2 and corresponding xl, my tests went well.
>> BTW: You could also try iommu=no-sharept to see if it helps.
> 
> Tried it and it doesn't help.
> I now even got a "xl dmesg" which shows a IO_PAGE_FAULT occuring very early, 
> before any toolstack or guest can be involved:
> 
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a05, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a06, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a07, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0b00, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] Scrubbing Free RAM: 
> ...........................<0>AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 
> 0x0a06, fault address = 0xc2c2c2c0

Looks like use of uninitialized memory (assuming you're using a
debug hypervisor, that's the pattern scrub_one_page() puts
there). But it's unclear to me what device should be doing any
I/O at that point (and even if one does, how it would get the
bad address loaded). What is 0a:00.6?

Jan


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