All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Julien Grall <julien.grall@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Riku Voipio <riku.voipio@linaro.org>, Tim Deegan <tim@xen.org>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org,
	Tamas K Lengyel <tklengyel@sec.in.tum.de>
Subject: Re: [PATCH] xen/arm: Make local_events_need_delivery working with idle VPCU
Date: Mon, 27 Apr 2015 17:32:09 +0100	[thread overview]
Message-ID: <553E6489.30300@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1504271634550.2640@kaball.uk.xensource.com>

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@linaro.org>
>> Signed-off-by: Julien Grall <julien.grall@citrix.com>
>> CC: Tamas K Lengyel <tklengyel@sec.in.tum.de>
>>
>> ---
>>
>> 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

  reply	other threads:[~2015-04-27 16:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27 14:39 [PATCH] xen/arm: Make local_events_need_delivery working with idle VPCU Julien Grall
2015-04-27 15:36 ` Stefano Stabellini
2015-04-27 16:32   ` Julien Grall [this message]
2015-05-04 11:44     ` Riku Voipio
2015-05-04 11:50       ` Julien Grall
2015-05-05 11:40     ` Ian Campbell
2015-05-05 11:48       ` Stefano Stabellini
2015-05-05 12:00       ` Julien Grall
2015-05-05 12:29         ` Ian Campbell
2015-05-05 14:37           ` Julien Grall
2015-04-27 15:40 ` Tamas K Lengyel
2015-04-27 16:13   ` Julien Grall
2015-04-27 16:25     ` Tamas K Lengyel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=553E6489.30300@citrix.com \
    --to=julien.grall@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=riku.voipio@linaro.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=tklengyel@sec.in.tum.de \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.