[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/arm: Make local_events_need_delivery working with idle VPCU
Hi Stefano, On 27/04/15 16:36, Stefano Stabellini wrote: > On Mon, 27 Apr 2015, Julien Grall wrote: >> The commit 569fb6c "xen/arm: Data abort exception (R/W) mem_access >> events" makes apply_p2m_changes to call hypercall_preempt_check for any >> operation rather than for relinquish. >> >> The function hypercall_preempt_check call local_events_need_delivery >> which rely on the current VCPU is not an idle VCPU. >> Although, during DOM0 building the current VCPU is an idle one. This >> would make Xen crash with the following stack trace: >> >> (XEN) CPU0: Unexpected Trap: Data Abort >> [...] >> (XEN) Xen call trace: >> (XEN) [<00256ef4>] apply_p2m_changes+0x210/0x1190 (PC) >> (XEN) [<002506b4>] gic_events_need_delivery+0x5c/0x13c (LR) >> (XEN) [<002580ec>] map_mmio_regions+0x64/0x74 >> (XEN) [<00251958>] gicv2v_setup+0xf8/0x150 >> (XEN) [<00250964>] gicv_setup+0x20/0x30 >> (XEN) [<0024cb3c>] arch_domain_create+0x170/0x244 >> (XEN) [<00207df0>] domain_create+0x2ac/0x4d8 >> (XEN) [<0028e3d0>] start_xen+0xcbc/0xee4 >> (XEN) [<00200540>] paging+0x94/0xd8 >> (XEN) >> (XEN) >> (XEN) **************************************** >> (XEN) Panic on CPU 0: >> (XEN) CPU0: Unexpected Trap: Data Abort >> (XEN) >> (XEN) **************************************** >> >> As an idle VCPU can never receive an event, return 0 when the current >> VCPU is an idle VCPU in local_events_need_delivery. >> >> Reported-by: Riku Voipio <riku.voipio@xxxxxxxxxx> >> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> >> CC: Tamas K Lengyel <tklengyel@xxxxxxxxxxxxx> >> >> --- >> >> This bug has been catched during boot on Mustang. This is because we >> have to map large chunk of PCI memory region. >> >> I was able to reproduce the bug on midway by lowering down >> preempt_count_limit to 16 in apply_p2m_changes. >> >> Although, I'm not sure this is the right fix for the bug. >> --- >> xen/include/asm-arm/event.h | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h >> index 5330dfe..0149d06 100644 >> --- a/xen/include/asm-arm/event.h >> +++ b/xen/include/asm-arm/event.h >> @@ -39,7 +39,12 @@ static inline int local_events_need_delivery_nomask(void) >> >> static inline int local_events_need_delivery(void) >> { >> - if ( !vcpu_event_delivery_is_enabled(current) ) >> + struct vcpu *v = current; >> + >> + if ( unlikely(is_idle_vcpu(v)) ) >> + return 0; >> + >> + if ( !vcpu_event_delivery_is_enabled(v) ) >> return 0; >> return local_events_need_delivery_nomask(); >> } > > Is it actually considered correct in Xen to call hypercall_preempt_check > and/or local_events_need_delivery on the idle vcpu? It seems that the x86 version of hypercall_preempt_check is able to cope with idle VCPU. Although, I'm not sure if there is path where hypercall_preempt_check can be called on an idle VCPU (cc x86 maintainers for this purpose). > Shouldn't it be avoided and maybe a BUG_ON added here instead? This patch was the simple way to fix the bug. I have other ideas in mind which require some rework in apply_p2m_changes. I'll wait to see what x86 maintainers think. Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |