All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Parth Dixit <parth.dixit@linaro.org>
Cc: Christoffer Dall <christoffer.dall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH RFC] xen/arm : emulation of arm's psci v0.2 standard
Date: Mon, 23 Jun 2014 13:30:15 +0100	[thread overview]
Message-ID: <53A81DD7.8060100@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1406231127110.19982@kaball.uk.xensource.com>

On 06/23/2014 11:40 AM, Stefano Stabellini wrote:
> On Mon, 23 Jun 2014, Parth Dixit wrote:
>> Next version of my patch is ready except for following things on which i need your suggestion
>> 1. Exposing PSCI v0.2 functions in device tree - This was not done because it gives the impression that you can modify the function id's
>> and kernel will call the function id's based on function id's exposed in device tree whereas kernel ignores it for PSCI v0.2 while it
>> follows it for PSCI v0.1 which can be confusing. Either way is fine with me.
>> 2.  Why do you clear the IRQ flag in psci_suspend - I am taking cue from the "vcpu_block_enable_events" in xen/common/schedule.c where
>> flag is cleared to enable interrupts before pausing the cpu.
> 
> Keep in mind that vcpu_block_enable_events is common code, while
> local_event_delivery_enable is the arm specific implementation.
> 
> In the arm case local_event_delivery_enable is implemented by clearing
> PSR_IRQ_MASK because effectively that's what is needed to enable event
> delivery. Events are just a Xen specific kind of interrupts.
> 
> vcpu_block_enable_events calls local_event_delivery_enable before
> blocking a vcpu, to make sure it can wake the vcpu up if an event needs
> to be delivered to it.
> 
> We need to clear PSR_IRQ_MASK because the CPU_SUSPEND call "is intended
> for use in idle subsystems where the core is expected to return to
> execution through a wake up event". The vcpu is never going to come up
> again if we don't clear PSR_IRQ_MASK, because events wouldn't be
> delivered to it.

With this solution Xen will return into the guest with IRQ enable
unconditionally.

I don't see anything in the specification that allow a such change. So
the guest may assume that the IRQs are still disabled. This would break it.

Couldn't we use the same trick as WFI ie:

vcpu_block();
if ( local_events_delivery_nomask() )
  vcpu_unblock(current);

It might be better to introduce a new helper for this purpose.

Regards,

-- 
Julien Grall

  reply	other threads:[~2014-06-23 12:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-19 10:14 PSCI v0.2 Emulation support in xen ( arm ) Parth Dixit
2014-06-19 10:14 ` [PATCH RFC] xen/arm : emulation of arm's psci v0.2 standard Parth Dixit
2014-06-19 12:47   ` Julien Grall
2014-06-19 16:00   ` Stefano Stabellini
2014-06-19 16:39     ` Julien Grall
2014-06-19 17:22       ` Stefano Stabellini
2014-06-19 18:02         ` Julien Grall
2014-06-19 18:20           ` Christoffer Dall
2014-06-20 11:48             ` Stefano Stabellini
2014-06-20 12:02               ` Julien Grall
2014-06-23  5:28                 ` Parth Dixit
2014-06-23  7:55                   ` Christoffer Dall
2014-06-23 10:28                     ` Stefano Stabellini
2014-06-23 10:40                   ` Stefano Stabellini
2014-06-23 12:30                     ` Julien Grall [this message]
2014-06-23 16:57                       ` Stefano Stabellini
2014-06-23 17:19                         ` Julien Grall
2014-06-24  8:35                           ` Christoffer Dall
2014-06-19 12:05 ` PSCI v0.2 Emulation support in xen ( arm ) Julien Grall

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=53A81DD7.8060100@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=christoffer.dall@linaro.org \
    --cc=parth.dixit@linaro.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.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.