Re: [Xen-devel] Xen 4.6.0-rc1 build with lock_profile=y crash_debug=y, frame_pointer=y and domain.c:241: error: negative width in bit-field â<anonymous>â

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Aug 26, 2015 at 01:37:12PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 26, 2015 at 01:32:54AM -0600, Jan Beulich wrote:
> > >>> On 25.08.15 at 21:54, <konrad.wilk@xxxxxxxxxx> wrote:
> > > On Tue, Aug 25, 2015 at 03:52:15PM -0400, Konrad Rzeszutek Wilk wrote:
> > >> On Tue, Aug 25, 2015 at 06:41:06PM +0100, Andrew Cooper wrote:
> > >> > On 25/08/15 18:09, Konrad Rzeszutek Wilk wrote:
> > >> > > --- a/xen/arch/x86/domain.c
> > >> > > +++ b/xen/arch/x86/domain.c
> > >> > > @@ -238,7 +238,9 @@ struct domain *alloc_domain_struct(void)
> > >> > >      if ( unlikely(!bits) )
> > >> > >           bits = _domain_struct_bits();
> > >> > >  
> > >> > > +#ifndef LOCK_PROFILE
> > >> > >      BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> > >> > > +#endif
> > >> > >      d = alloc_xenheap_pages(0, MEMF_bits(bits));
> > >> > >      if ( d != NULL )
> > >> > >          clear_page(d);
> > >> > >
> > >> > > (not compile tested nor runtime tested)
> > >> > 
> > >> > Either remove it locally for debugging, or use something like
> > > 
> > > I forgot to mention that by removing it locally Xen ends up halting at:
> > > 
> > > (XEN) Detected 3292.657 MHz processor.
> > 
> > Sure - as Andrew said on irc, neither simply removing it nor replacing
> > it by vmalloc() can actually work. At the very least you'd want the
> > above to become
> 
> I ended up doing:
> 
> >From 52548151b6db3724fdafd005f52fc1aaefa65eff Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> Date: Tue, 25 Aug 2015 21:25:54 -0400
> Subject: [PATCH] x86: Allow 'struct domain' to expand past PAGE_SIZE
> 
> If we are building with lock profilling enabled - as that
> expands the spinlock structures considerably.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> ---
>  xen/arch/x86/domain.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 045f6ff..7df58d8 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -237,9 +237,10 @@ struct domain *alloc_domain_struct(void)
>  
>      if ( unlikely(!bits) )
>           bits = _domain_struct_bits();
> -
> +#ifndef LOCK_PROFILE
>      BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> -    d = alloc_xenheap_pages(0, MEMF_bits(bits));
> +#endif
> +    d = alloc_xenheap_pages(get_order_from_bytes(sizeof(*d)), 
> MEMF_bits(bits));
>      if ( d != NULL )
>          clear_page(d);
>      return d;
> @@ -261,7 +262,7 @@ struct vcpu *alloc_vcpu_struct(void)
>       * structure must satisfy this restriction. Thus we specify 
> MEMF_bits(32).
>       */
>      BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
> -    v = alloc_xenheap_pages(0, MEMF_bits(32));
> +    v = alloc_xenheap_pages(get_order_from_bytes(sizeof(*v)), MEMF_bits(32));
>      if ( v != NULL )
>          clear_page(v);

clear_page() works on PAGE_SIZE page so if you allocate order 2 page it
is not sufficient.

Wei.

>      return v;
> -- 
> 2.1.0
> 
> 
> which made it compile and boot. However the moment I ran xenlockprof I got
> this nice splash:
> 
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82d08012e0fa>] spinlocerate+0x5b/0x96
> (XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor (d0v0)
> (XEN) rax: ffff83009e6f7e40   rbx: c2c2c2c2c2c2c2c2   rcx: ffff83009e6f7d48
> (XEN) rdx: 000000000000003d   rsi: 0000000000000001   rdi: c2c2c2c2c2c2c2c2
> (XEN) rbp: ffff83009e6f7d38   rsp: ffff83009e6f7cf8   r8:  00000000deadbeef
> (XEN) r9:  00000000deadbeef   r10: ffff82d0802542a0   r11: 0000000000000286
> (XEN) r12: ffff830413381078   r13: 0000000000000001   r14: ffff82d08012da37
> (XEN) r15: ffff83009e6f7d48   cr0: 0000000080050033   cr4: 00000000000426e0
> (XEN) cr3: 0000000411303000   cr2: 00007f42d4a6e9a0
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=ffff83009e6f7cf8:
> (XEN)    0000000000411fc1 ffff82d080327ef0 ffff830400000000 ffff83009e6f7e40
> (XEN)    00007f42d4ea4004 ffff83009e6f7f18 ffff83009e6f7f18 ffff82d08031be00
> (XEN)    ffff83009e6f7d68 ffff82d08012e1e5 ffff83009e6f7e40 ffff82d000000000
> (XEN)    0000000000000000 ffffffffffffffff ffff83009e6f7ef8 ffff82d08012f3fa
> (XEN)    ffff83009e6f7d98 ffff83042c186000 ffff83009e8b0000 ffff83009e6f7d98
> (XEN)    ffff83009e6f7f18 ffff83009e6f7f18 ffff83009e6f7f18 ffff83009e6f7f18
> (XEN)    ffff83009e6f7f18 ffff83009e6f7f18 ffff83009e6f7f18 0000000000000000
> (XEN)    ffff83009e6f7eb0 ffff83009e6f7ea8 ffff88008020ab10 0000000000411fc1
> (XEN)    0000000000000000 ffff830000000007 0000000300007ff0 ffff820040008000
> (XEN)    ffff83009e8b0000 8000000402e3d067 0000000400000002 ffff83009e6f7f18
> (XEN)    0000000c0000000f 0000000000000002 00007ffd0000003e 0000000000000000
> (XEN)    0000000000000000 00007f42d4a5a8e8 00000000010eb050 0000000000000000
> (XEN)    00007ffd86253bd0 00000000004008f0 00007ffd86253cb0 00007f42d4ca07c5
> (XEN)    00000000010eb050 00007f42d47ae695 00007ffd86253b68 00007ffd86253b68
> (XEN)    00000000010eb050 0000000000000033 ffff83009e6f7ed8 ffff83009e8b0000
> (XEN)    ffff880068795900 ffff88007395dd88 0000000000000003 00007ffd86253900
> (XEN)    00007cff619080c7 ffff82d0802396d2 ffffffff8100146a 0000000000000023
> (XEN)    0000000000000000 0000000000000000 00007ffd86253cb0 00000000004008f0
> (XEN)    ffff8800686d3e68 00007ffd86253900 0000000000000286 00007ffd862539b0
> (XEN)    00007ffd86253b68 00007f42d4c95256 0000000000000023 ffffffff8100146a
> (XEN) Xen call trace:
> (XEN)    [<ffff82d08012e0fa>] spinlock_profile_iterate+0x5b/0x96
> (XEN)    [<ffff82d08012e1e5>] spinlock_profile_control+0x52/0x6c
> (XEN)    [<ffff82d08012f3fa>] do_sysctl+0x33a/0x10c0
> (XEN)    [<ffff82d0802396d2>] lstar_enter+0xe2/0x13c
> (XEN) 
> (XEN) 
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) GENERAL PROTECTION FAULT
> (XEN) [error_code=0000]
> (XEN) ****************************************
> (XEN) 
> (XEN) Reboot in five seconds...
> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
> 
> Off to figure this one out (http://darnok.org/xen-syms is where the binary is
> in case any one else wants to jump on this) next week.

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