| Message ID | 53610B51.8030701@linaro.org |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
>>> On 30.04.14 at 16:40, <julien.grall@linaro.org> wrote: > I played a bit with the function vcpu_initialize on ARM. > If it fails, it will likely crash Xen with the following stack trace: > > (XEN) Xen BUG at /local/home/julien/works/arndale/xen/xen/include/xen/list.h:175 > ... > (XEN) Xen call trace: > (XEN) [<002457e0>] __bug+0x2c/0x44 (PC) > (XEN) [<002457e0>] __bug+0x2c/0x44 (LR) > (XEN) [<00231cb0>] kill_timer+0x1bc/0x364 > (XEN) [<002296e4>] sched_destroy_vcpu+0x1c/0x14c > (XEN) [<002081d8>] alloc_vcpu+0x17c/0x270 > (XEN) [<00206a10>] do_domctl+0xa74/0x11f4 > (XEN) [<00254698>] do_trap_hypervisor+0x7f0/0xb44 > (XEN) [<00257110>] return_from_trap+0/0x4 > > It's easily reproductible on ARM with this small patch: > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index ccccb77..7ada03f 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -473,6 +473,9 @@ int vcpu_initialise(struct vcpu *v) > if ( (rc = vcpu_vtimer_init(v)) != 0 ) > return rc; > > + if ( v->domain->domain_id != 0 ) > + return -EFAULT; > + > return rc; > } > > I guess we forget to take a lock or smth like that, but I don't know > enough this code. I definitely can't reproduce this on x86 - I tried three different variations of which vCPU(s) to fail this function on. Are you sure you didn't corrupt something with your experiments? Jan
On 04/30/2014 04:49 PM, Jan Beulich wrote: >>>> On 30.04.14 at 16:40, <julien.grall@linaro.org> wrote: >> I played a bit with the function vcpu_initialize on ARM. >> If it fails, it will likely crash Xen with the following stack trace: >> >> (XEN) Xen BUG at /local/home/julien/works/arndale/xen/xen/include/xen/list.h:175 >> ... >> (XEN) Xen call trace: >> (XEN) [<002457e0>] __bug+0x2c/0x44 (PC) >> (XEN) [<002457e0>] __bug+0x2c/0x44 (LR) >> (XEN) [<00231cb0>] kill_timer+0x1bc/0x364 >> (XEN) [<002296e4>] sched_destroy_vcpu+0x1c/0x14c >> (XEN) [<002081d8>] alloc_vcpu+0x17c/0x270 >> (XEN) [<00206a10>] do_domctl+0xa74/0x11f4 >> (XEN) [<00254698>] do_trap_hypervisor+0x7f0/0xb44 >> (XEN) [<00257110>] return_from_trap+0/0x4 >> >> It's easily reproductible on ARM with this small patch: >> >> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c >> index ccccb77..7ada03f 100644 >> --- a/xen/arch/arm/domain.c >> +++ b/xen/arch/arm/domain.c >> @@ -473,6 +473,9 @@ int vcpu_initialise(struct vcpu *v) >> if ( (rc = vcpu_vtimer_init(v)) != 0 ) >> return rc; >> >> + if ( v->domain->domain_id != 0 ) >> + return -EFAULT; >> + >> return rc; >> } >> >> I guess we forget to take a lock or smth like that, but I don't know >> enough this code. > > I definitely can't reproduce this on x86 - I tried three different > variations of which vCPU(s) to fail this function on. Are you sure > you didn't corrupt something with your experiments? Yes, I've checkout xengit/staging (commit 9f2f129) and applied tiny patch above. Usually the first iteration I get: Parsing config from dom1.xl libxl: error: libxl_dom.c:239:libxl__build_pre: Couldn't set max vcpu count libxl: error: libxl_create.c:1036:domcreate_rebuild_done: cannot (re-)build domain: -3 And then Xen will crash as soon as I try to create another domain. I will investigate in ARM side to see what happen. Regards,
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index ccccb77..7ada03f 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -473,6 +473,9 @@ int vcpu_initialise(struct vcpu *v) if ( (rc = vcpu_vtimer_init(v)) != 0 ) return rc; + if ( v->domain->domain_id != 0 ) + return -EFAULT; + return rc; }