Re: [Xen-devel] Debian Wheezy installer crashes guest when EPT is enabled

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Apr 22, 2014 at 12:18:24PM +0100, Jan Beulich wrote:
> >>> On 18.04.14 at 16:08, <wei.liu2@xxxxxxxxxx> wrote:
> > (d2) Booting from DVD/CD...
> > (d2) Booting from 0000:7c00
> > (XEN) stdvga.c:151:d2v0 leaving stdvga
> > [  261.416031] xenbr0: port 3(vif2.0-emu) entered forwarding state
> > (XEN) hap.c:273: d2 failed to allocate from HAP pool<G><0>vmx.c:3063:d2v0 
> > Bad 
> > vmexit (reason 0x31)
> > (XEN) domain_crash called from vmx.c:3064
> > (XEN) Domain 2 (vcpu#0) crashed on cpu#7:
> > (XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Tainted:    C ]----
> > (XEN) CPU:    7
> > (XEN) RIP:    0010:[<ffffffff811b2ab2>]
> > (XEN) RFLAGS: 0000000000010016   CONTEXT: hvm guest
> > (XEN) rax: 0000000000000000   rbx: ffffffff81601d30   rcx: 000000000000003f
> > (XEN) rdx: 8000000000000163   rsi: ffffffff81732ba0   rdi: ffffffffff4b8000
> > (XEN) rbp: 00000000efffc000   rsp: ffffffff81601cd0   r8:  8000000000000163
> > (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> > (XEN) r12: ffffffffff4b8000   r13: 0000000148000000   r14: 0000000000000000
> > (XEN) r15: 0000000148000000   cr0: 0000000080050033   cr4: 00000000000000b0
> > (XEN) cr3: 0000000001605000   cr2: 0000000000000000
> > (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: 0010
> 
> Are you (or the tools you use) perhaps setting a particularly small
> shadow allocation size (which is what gets interpreted as the HAP pool
> one)? When I run a 2-vCPU guest (SLES, not Wheezy), I see

It should be using value calculated by toolstack. I didn't have shadow=
in my config file.

> - for memory=2048 0x46 P2M pages out of a HAP pool of 0x1200
> - for memory=4096 0x4d P2M pages out of a HAP pool of 0x2200
> - for memory=4864 0x76 P2M pages out of a HAP pool of 0x2800
> And I have no reason to believe that the numbers would dramatically
> change if I bumped the domain size to 5G (the system has got only 6G,
> and I don't want to trouble Dom0 too much). The almost doubling of
> the P2M page count is presumably attributed to the fact that there are
> not enough contiguous 2Mb pages left anymore, i.e. 4k pages (and
> hence more page tables) are being used.
> 
> If that's not it, or if you're not certain, would you mind giving the
> attached debugging patch a try?

Here's the output.

(d1)   NULL
(d1) Booting from DVD/CD...
(d1) Booting from 0000:7c00
(XEN) stdvga.c:151:d1v0 leaving stdvga
(XEN) d1: p2m=40 (29be/29c0)
(XEN) d1: p2m=80 (297e/2980)
(XEN) d1: p2m=100 (28fe/2900)
(XEN) d1: p2m=200 (27fe/2800)
(XEN) d1: p2m=400 (25fe/2600)
(XEN) d1: p2m=800 (21fe/2200)
(XEN) d1: p2m=1000 (19fe/1a00)
(XEN) d1: p2m=2000 (9fe/a00)
(XEN) hap.c:278: d1 failed to allocate from HAP pool (free=0 tot=2 p2m=29fe)
(XEN) vmx.c:3063:d1v0 Bad vmexit (reason 0x31)
(XEN) domain_crash called from vmx.c:3064
(XEN) Domain 1 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.5-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    0010:[<ffffffff811b2ab2>]
(XEN) RFLAGS: 0000000000010016   CONTEXT: hvm guest
(XEN) rax: 0000000000000000   rbx: ffffffff81601d30   rcx: 000000000000003f
(XEN) rdx: 8000000000000163   rsi: ffffffff81732ba0   rdi: ffffffffff4b8000
(XEN) rbp: 00000000efffc000   rsp: ffffffff81601cd0   r8:  8000000000000163
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: ffffffffff4b8000   r13: 0000000148000000   r14: 0000000000000000
(XEN) r15: 0000000148000000   cr0: 0000000080050033   cr4: 00000000000000b0
(XEN) cr3: 0000000001605000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: 0010

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