From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH] x86/HVM: Merge HVM and PVH hypercall tables Date: Mon, 14 Dec 2015 16:25:46 -0500 Message-ID: <566F33DA.7020206@oracle.com> References: <1449584401-8794-1-git-send-email-boris.ostrovsky@oracle.com> <56697E8F02000078000BE17D@prv-mh.provo.novell.com> <5669ADF2.9090603@oracle.com> <566AFEF2.5020306@oracle.com> <566E832902000078000BEF24@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <566E832902000078000BEF24@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: andrew.cooper3@citrix.com, xen-devel@lists.xen.org, roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org On 12/14/2015 02:51 AM, Jan Beulich wrote: >>>> On 11.12.15 at 17:50, wrote: >> On 12/10/2015 11:53 AM, Boris Ostrovsky wrote: >>> Especially given that PVH dom0 is not booting for me, as I just found >>> out: >>> >>> ... >>> (XEN) d0v0 EPT violation 0x1aa (-w-/r-x) gpa 0x000000c0008116 mfn >>> 0xc0008 type 5 >>> (XEN) d0v0 Walking EPT tables for GFN c0008: >>> (XEN) d0v0 epte 800000082bf50007 >>> (XEN) d0v0 epte 800000082bf19007 >>> (XEN) d0v0 epte 800000043c6f9007 >>> (XEN) d0v0 epte 80500000c0008805 >>> (XEN) d0v0 --- GLA 0xffffc90020008116 >>> (XEN) domain_crash called from vmx.c:2816 >>> (XEN) Domain 0 (vcpu#0) crashed on cpu#0: >>> (XEN) ----[ Xen-4.7-unstable x86_64 debug=y Tainted: C ]---- >>> (XEN) CPU: 0 >>> (XEN) RIP: 0010:[] >>> (XEN) RFLAGS: 0000000000010046 CONTEXT: hvm guest (d0v0) >>> (XEN) rax: 000000000000001d rbx: 0000000000000000 rcx: >>> ffff88014700f9b8 >>> (XEN) rdx: 00000000000000ff rsi: 0000000000000000 rdi: >>> 0000000000000000 >>> (XEN) rbp: ffff88014700fa18 rsp: ffff88014700f9e8 r8: >>> ffff88014700f9c0 >>> (XEN) r9: 000000000000001d r10: ffffffff8189c7f0 r11: >>> 0000000000000000 >>> (XEN) r12: ffffc90020008000 r13: ffffc90020008116 r14: >>> 0000000000000002 >>> (XEN) r15: 000000000000001d cr0: 0000000080050033 cr4: >>> 00000000000406f0 >>> (XEN) cr3: 0000000001c0e000 cr2: 0000000000000000 >>> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0010 >>> (XEN) Guest stack trace from rsp=ffff88014700f9e8: >>> (XEN) Fault while accessing guest memory. >>> (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. >>> >>> >>> We haven't been running regression tests for PVH dom0 so I don't know >>> how long this has been broken. >> >> This is broken by 9256f66c1606 ("x86/PCI: intercept all PV Dom0 MMCFG >> writes"). > Well, I can't find any hookup of the write emulation logic for PVH > at all in ept_handle_violation() or hvm_hap_nested_page_fault(), > i.e. it looks to me as if this was broken already before, just that > for the limited set of devices that had their MMCFG space marked > r/o this went unnoticed (iow perhaps a missing FIXME annotation). > I'll see to find time to look into this, but I can't really predict when > I might get around to it. I added handling for MMCFG to ept_handle_violation() and that indeed fixed it (but it should really go to hvm_hap_nested_page_fault() since we will want AMD support for that as well). I'll try to come up with a patch in the next day or two. -boris