linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "tiejun.chen" <tiejun.chen@windriver.com>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
	kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
Date: Tue, 7 May 2013 09:56:25 +0800	[thread overview]
Message-ID: <51885F49.6060605@windriver.com> (raw)
In-Reply-To: <1367884257.3398.9@snotra>

On 05/07/2013 07:50 AM, Scott Wood wrote:
> On 05/05/2013 10:13:17 PM, tiejun.chen wrote:
>> On 05/06/2013 11:10 AM, Tiejun Chen wrote:
>>> For the external interrupt, the decrementer exception and the doorbell
>>> excpetion, we also need to soft-disable interrupts while doing as host
>>> interrupt handlers since the DO_KVM hook is always performed to skip
>>> EXCEPTION_COMMON then miss this original chance with the 'ints' (INTS_DISABLE).
>
> http://patchwork.ozlabs.org/patch/241344/
> http://patchwork.ozlabs.org/patch/241412/
>
> :-)

I'm observing the same behaviour as well:

	WARN_ON_ONCE(!irqs_disabled());

>
>>> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
>>> ---
>>>   arch/powerpc/kvm/bookehv_interrupts.S |    9 +++++++++
>>>   1 file changed, 9 insertions(+)
>>>
>>> diff --git a/arch/powerpc/kvm/bookehv_interrupts.S
>>> b/arch/powerpc/kvm/bookehv_interrupts.S
>>> index e8ed7d6..2fd62bf 100644
>>> --- a/arch/powerpc/kvm/bookehv_interrupts.S
>>> +++ b/arch/powerpc/kvm/bookehv_interrupts.S
>>> @@ -33,6 +33,8 @@
>>>
>>>   #ifdef CONFIG_64BIT
>>>   #include <asm/exception-64e.h>
>>> +#include <asm/hw_irq.h>
>>> +#include <asm/irqflags.h>
>>>   #else
>>>   #include "../kernel/head_booke.h" /* for THREAD_NORMSAVE() */
>>>   #endif
>>> @@ -469,6 +471,13 @@ _GLOBAL(kvmppc_resume_host)
>>>       PPC_LL    r3, HOST_RUN(r1)
>>>       mr    r5, r14 /* intno */
>>>       mr    r14, r4 /* Save vcpu pointer. */
>>> +#ifdef CONFIG_64BIT
>>> +    /* Should we soft-disable interrupts? */
>>> +    andi.    r6, r5, BOOKE_INTERRUPT_EXTERNAL | BOOKE_INTERRUPT_DECREMENTER
>>> | BOOKE_INTERRUPT_DOORBELL
>>> +    beq    skip_soft_dis
>>> +    SOFT_DISABLE_INTS(r7,r8)
>>> +skip_soft_dis:
>>> +#endif
>
> Why wouldn't we always disable them?  kvmppc_handle_exit() will enable
> interrupts when it's ready.

This only disable soft interrupt for kvmppc_restart_interrupt() that restarts 
interrupts if they were meant for the host:

a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL | 
BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL

b. bl      kvmppc_handle_exit

c. kvmppc_handle_exit()
{
         int r = RESUME_HOST;
         int s;

         /* update before a new last_exit_type is rewritten */
         kvmppc_update_timing_stats(vcpu);

         /* restart interrupts if they were meant for the host */
         kvmppc_restart_interrupt(vcpu, exit_nr);

         local_irq_enable();	==> Enable again.
....

And shouldn't we handle kvmppc_restart_interrupt() like the original HOST flow?

#define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr, ack)           \
         START_EXCEPTION(label);                                         \
         NORMAL_EXCEPTION_PROLOG(trapnum, intnum, PROLOG_ADDITION_MASKABLE)\
         EXCEPTION_COMMON(trapnum, PACA_EXGEN, *INTS_DISABLE*)             \
	...

So I think this should be reasonable :)

Tiejun

  reply	other threads:[~2013-05-07  1:56 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-06  3:10 [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts Tiejun Chen
2013-05-06  3:13 ` tiejun.chen
2013-05-06 23:50   ` Scott Wood
2013-05-07  1:56     ` tiejun.chen [this message]
2013-05-07  2:06       ` Scott Wood
2013-05-07  2:43         ` tiejun.chen
2013-05-07  3:04           ` Scott Wood
2013-05-08 13:14         ` Caraman Mihai Claudiu-B02008
2013-05-09  7:33           ` Bhushan Bharat-R65777
2013-05-09  7:47             ` tiejun.chen
2013-05-09  7:51               ` Bhushan Bharat-R65777
2013-05-09  8:04                 ` tiejun.chen
2013-05-09  8:08                 ` Kevin Hao
2013-05-09  8:12                   ` Bhushan Bharat-R65777
2013-05-09  8:17                     ` tiejun.chen
2013-05-09  8:26                       ` Bhushan Bharat-R65777
2013-05-09  8:21                     ` Kevin Hao
2013-05-09 12:26                       ` Benjamin Herrenschmidt
2013-05-09  8:23           ` Bhushan Bharat-R65777
2013-05-09  9:44             ` tiejun.chen
2013-05-09 10:00               ` Bhushan Bharat-R65777
2013-05-09 10:18                 ` tiejun.chen
2013-05-09 11:21                   ` Bhushan Bharat-R65777
2013-05-09 11:35                     ` tiejun.chen
2013-05-09 12:37               ` Benjamin Herrenschmidt
2013-05-09 13:28                 ` David Laight
2013-05-09 22:01                   ` Benjamin Herrenschmidt
2013-05-09 14:13                 ` Chen, Tiejun
2013-05-09 21:27                 ` Scott Wood
2013-05-09 22:07                   ` Benjamin Herrenschmidt
2013-05-09 22:13                     ` Scott Wood
2013-05-10 14:12                     ` Kevin Hao
2013-05-10 21:49                       ` Benjamin Herrenschmidt
2013-05-10 21:50                         ` Benjamin Herrenschmidt

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=51885F49.6060605@windriver.com \
    --to=tiejun.chen@windriver.com \
    --cc=agraf@suse.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=scottwood@freescale.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).