From mboxrd@z Thu Jan  1 00:00:00 1970
From: "tiejun.chen" <tiejun.chen@windriver.com>
Date: Thu, 11 Jul 2013 02:59:56 +0000
Subject: Re: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()
Message-Id: <51DE1FD1.90609@windriver.com>
List-Id: <kvm-ppc.vger.kernel.org>
References: <1373436139-27998-1-git-send-email-tiejun.chen@windriver.com> <1373483740.8183.223@snotra>
In-Reply-To: <1373483740.8183.223@snotra>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Scott Wood <scottwood@freescale.com>
Cc: agraf@suse.de, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org

On 07/11/2013 03:15 AM, Scott Wood wrote:
> On 07/10/2013 01:02:19 AM, Tiejun Chen wrote:
>> We should ensure the preemption cannot occur while calling get_paca()
>> insdide hard_irq_disable(), otherwise the paca_struct may be the
>> wrong one just after. And btw, we may update timing stats in this case.
>
> The soft-ee mechanism depends on accessing the PACA directly via r13 to avoid
> this.  We probably should be using inline asm to read was_enabled rather than

Yes.

> hoping the compiler doesn't do anything silly.

Do you recommend I should directly replace get_paca() with local_paca inside 
hard_irq_disable()?

#define hard_irq_disable()      do {                    \
         u8 _was_enabled = get_paca()->soft_enabled;     \

->	u8 _was_enabled = local_paca->soft_enabled;

But is this safe for all scenarios?

Tiejun