Re: [Xen-devel] PTE Write access is not set

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.12.11 at 09:05, Liwei <xieliwei@xxxxxxxxx> wrote:
>     Using the 3.1.5 kernel and 4.1.3-rc1-pre xen (Latest ChangeSet:

The kernel version is the HVM guest one or the host one, because ...

> Tue Dec 06 10:53:12 2011 +0000 23199:d9f8316a8291), these crashes
> occur after about a day or so of running a HVM:
> =================8<=================
> (XEN) realmode.c:115:d9 Failed to emulate insn.
> (XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
> 33 01 fc 30 34

... if this is Linux I'm having a rather hard time seeing why it would
enter realmode at normal run time (and then even use floating point
instructions there). This would be expected at boot time and at most
during guest-internal suspend/resume, but I'm sure you would have
mentioned if the guest was in the process of doing the latter (and
you excluded the former).

I'm rather suspecting the VM to have gone astray earlier.

> (XEN) domain_crash called from realmode.c:166
> (XEN) Domain 9 (vcpu#0) crashed on cpu#6:
> (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    6
> (XEN) RIP:    e40a:[<0000000000005f6c>]
> (XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
> (XEN) rax: 000000000000e7e5   rbx: 0000000000000000   rcx: 00000000000d0000
> (XEN) rdx: 00000000000001f7   rsi: 0000000000000000   rdi: 0000000000000dba
> (XEN) rbp: 0000000000000182   rsp: 0000000000000db0   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: e40a
> =================8<=================
> (XEN) realmode.c:115:d5 Failed to emulate insn.
> (XEN) realmode.c:165:d5 Real-mode emulation failed @ c5d5:000242bc: d9
> 33 01 fc 30 34
> (XEN) domain_crash called from realmode.c:166
> (XEN) Domain 5 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    c5d5:[<00000000000242bc>]
> (XEN) RFLAGS: 0000000000010013   CONTEXT: hvm guest
> (XEN) rax: 000000000000001b   rbx: 0000000000000702   rcx: 0000000000010ba7
> (XEN) rdx: 0000000000008fd5   rsi: 0000000000001333   rdi: 000000000000900e
> (XEN) rbp: 000000000000703e   rsp: 000000000000c5cf   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: c5d5

Further, you present two instances of a VM death, ...

> (XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [0d:00.1]
> fault addr d8964f44000, iommu reg = ffff82c3fff57000
> (XEN) DMAR:[fault reason 05h] PTE Write access is not set
> (XEN) print_vtd_entries: iommu = ffff83045ce565c0 bdf = d:0.1 gmfn = 
> d8964f44
> (XEN)     root_entry = ffff8304519d1000
> (XEN)     root_entry[d] = 4127af001
> (XEN)     context = ffff8304127af000
> (XEN)     context[1] = 2_414aca001
> (XEN)     l4 = ffff830414aca000
> (XEN)     l4_index = 1b
> (XEN)     l4[1b] = 0
> (XEN)     l4[1b] not present

... but only one instance of an IOMMU fault. Hence it's not even clear
they are connected. It also can't be the result of an immediate guest
restart, as the second VM that's dying has a lower numbered domain
ID than the first one.

Further, the IOMMU fault is not about the lack of write access, but the
requested mapping simply is not present at all. Which is because the gmfn
looks rather bogus - I doubt you're running a guest with nearly 14Tb
of memory (Xen doesn't even support that much) or with an extremely
spares physical address space (you would have to have arranged this
yourself, no VMs get created this way afaik).

Please provide consistent and complete information.

Jan

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