From: Scott Wood <scottwood@freescale.com>
To: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] KVM: PPC: Book3E 64: Fix IRQs warnings and hangs
Date: Fri, 03 May 2013 22:06:48 +0000 [thread overview]
Message-ID: <1367618808.19391.11@snotra> (raw)
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF3E9B37@039-SN2MPN1-013.039d.mgd.msft.net> (from B02008@freescale.com on Fri May 3 15:56:47 2013)
On 05/03/2013 03:56:47 PM, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, May 03, 2013 11:15 PM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: Wood Scott-B07421; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
> > linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH] KVM: PPC: Book3E 64: Fix IRQs warnings and
> hangs
> >
> > > > > The unresponsiveness has to do with the fact that
> > > > > arch_local_irq_restore()
> > > > > does not guarantees to hard enable interrupts.
> > > >
> > > > Could you elaborate? If the saved IRQ state was "enabled", why
> > > > wouldn't arch_local_irq_restore() hard-enable IRQs? The last
> thing
> > > it
> > > > does is __hard_irq_enable().
> > >
> > > if (!irq_happened)
> > > return;
> >
> > OK, so the problem is that we're not setting PACA_IRQ_HARD_DIS when
> we
> > hard-disable interrupts?
>
> We enter guest with local_irq_disable() which means soft disabled,
Hmm... I don't see any obvious breakage from that, but it makes me
nervous. I'd be more comfortable if we just hard-disabled interrupts
there.
> when do we hard-disable interrupts?
Interrupts will be hard-disabled when we take an exception to exit
guest state.
> If we follow host exception handlers model
> they set PACA_IRQ_EE/DEC/DBELL but not PACA_IRQ_HARD_DIS. Can you
> give it
> a try to see how KVM behaves with PACA_IRQ_HARD_DIS? I can't do it
> right now.
I replaced the two calls to kvmppc_lazy_ee_enable() with calls to
hard_irq_disable(), and it seems to be working fine.
> > > > Where is the arch_local_irq_restore() instance you're talking
> about?
> > >
> > > ./arch/power/kernel/irq.c
> >
> > I meant the caller. :-P
>
> ./arch/powerpc/include/asm/hw_irq.h
>
> 55static inline unsigned long arch_local_irq_disable(void)
> 56{
> 57 unsigned long flags, zero;
> 58
> 59 asm volatile(
> 60 "li %1,0; lbz %0,%2(13); stb %1,%2(13)"
> 61 : "=r" (flags), "=&r" (zero)
> 62 : "i" (offsetof(struct paca_struct, soft_enabled))
> 63 : "memory");
> 64
> 65 return flags;
> 66}
> 67
> 68extern void arch_local_irq_restore(unsigned long);
> 69
> 70static inline void arch_local_irq_enable(void)
> 71{
> 72 arch_local_irq_restore(1);
> 73}
Sigh. I meant the real caller, who's calling local_irq_restore().
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>
Subject: Re: [PATCH] KVM: PPC: Book3E 64: Fix IRQs warnings and hangs
Date: Fri, 3 May 2013 17:06:48 -0500 [thread overview]
Message-ID: <1367618808.19391.11@snotra> (raw)
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF3E9B37@039-SN2MPN1-013.039d.mgd.msft.net> (from B02008@freescale.com on Fri May 3 15:56:47 2013)
On 05/03/2013 03:56:47 PM, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, May 03, 2013 11:15 PM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: Wood Scott-B07421; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
> > linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH] KVM: PPC: Book3E 64: Fix IRQs warnings and =20
> hangs
> >
> > > > > The unresponsiveness has to do with the fact that
> > > > > arch_local_irq_restore()
> > > > > does not guarantees to hard enable interrupts.
> > > >
> > > > Could you elaborate? If the saved IRQ state was "enabled", why
> > > > wouldn't arch_local_irq_restore() hard-enable IRQs? The last =20
> thing
> > > it
> > > > does is __hard_irq_enable().
> > >
> > > if (!irq_happened)
> > > return;
> >
> > OK, so the problem is that we're not setting PACA_IRQ_HARD_DIS when =20
> we
> > hard-disable interrupts?
>=20
> We enter guest with local_irq_disable() which means soft disabled,
Hmm... I don't see any obvious breakage from that, but it makes me =20
nervous. I'd be more comfortable if we just hard-disabled interrupts =20
there.
> when do we hard-disable interrupts?
Interrupts will be hard-disabled when we take an exception to exit =20
guest state.
> If we follow host exception handlers model
> they set PACA_IRQ_EE/DEC/DBELL but not PACA_IRQ_HARD_DIS. Can you =20
> give it
> a try to see how KVM behaves with PACA_IRQ_HARD_DIS? I can't do it =20
> right now.
I replaced the two calls to kvmppc_lazy_ee_enable() with calls to =20
hard_irq_disable(), and it seems to be working fine.
> > > > Where is the arch_local_irq_restore() instance you're talking =20
> about?
> > >
> > > ./arch/power/kernel/irq.c
> >
> > I meant the caller. :-P
>=20
> ./arch/powerpc/include/asm/hw_irq.h
>=20
> 55static inline unsigned long arch_local_irq_disable(void)
> 56{
> 57 unsigned long flags, zero;
> 58
> 59 asm volatile(
> 60 "li %1,0; lbz %0,%2(13); stb %1,%2(13)"
> 61 : "=3Dr" (flags), "=3D&r" (zero)
> 62 : "i" (offsetof(struct paca_struct, soft_enabled))
> 63 : "memory");
> 64
> 65 return flags;
> 66}
> 67
> 68extern void arch_local_irq_restore(unsigned long);
> 69
> 70static inline void arch_local_irq_enable(void)
> 71{
> 72 arch_local_irq_restore(1);
> 73}
Sigh. I meant the real caller, who's calling local_irq_restore().
-Scott=
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] KVM: PPC: Book3E 64: Fix IRQs warnings and hangs
Date: Fri, 3 May 2013 17:06:48 -0500 [thread overview]
Message-ID: <1367618808.19391.11@snotra> (raw)
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF3E9B37@039-SN2MPN1-013.039d.mgd.msft.net> (from B02008@freescale.com on Fri May 3 15:56:47 2013)
On 05/03/2013 03:56:47 PM, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, May 03, 2013 11:15 PM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: Wood Scott-B07421; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
> > linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH] KVM: PPC: Book3E 64: Fix IRQs warnings and
> hangs
> >
> > > > > The unresponsiveness has to do with the fact that
> > > > > arch_local_irq_restore()
> > > > > does not guarantees to hard enable interrupts.
> > > >
> > > > Could you elaborate? If the saved IRQ state was "enabled", why
> > > > wouldn't arch_local_irq_restore() hard-enable IRQs? The last
> thing
> > > it
> > > > does is __hard_irq_enable().
> > >
> > > if (!irq_happened)
> > > return;
> >
> > OK, so the problem is that we're not setting PACA_IRQ_HARD_DIS when
> we
> > hard-disable interrupts?
>
> We enter guest with local_irq_disable() which means soft disabled,
Hmm... I don't see any obvious breakage from that, but it makes me
nervous. I'd be more comfortable if we just hard-disabled interrupts
there.
> when do we hard-disable interrupts?
Interrupts will be hard-disabled when we take an exception to exit
guest state.
> If we follow host exception handlers model
> they set PACA_IRQ_EE/DEC/DBELL but not PACA_IRQ_HARD_DIS. Can you
> give it
> a try to see how KVM behaves with PACA_IRQ_HARD_DIS? I can't do it
> right now.
I replaced the two calls to kvmppc_lazy_ee_enable() with calls to
hard_irq_disable(), and it seems to be working fine.
> > > > Where is the arch_local_irq_restore() instance you're talking
> about?
> > >
> > > ./arch/power/kernel/irq.c
> >
> > I meant the caller. :-P
>
> ./arch/powerpc/include/asm/hw_irq.h
>
> 55static inline unsigned long arch_local_irq_disable(void)
> 56{
> 57 unsigned long flags, zero;
> 58
> 59 asm volatile(
> 60 "li %1,0; lbz %0,%2(13); stb %1,%2(13)"
> 61 : "=r" (flags), "=&r" (zero)
> 62 : "i" (offsetof(struct paca_struct, soft_enabled))
> 63 : "memory");
> 64
> 65 return flags;
> 66}
> 67
> 68extern void arch_local_irq_restore(unsigned long);
> 69
> 70static inline void arch_local_irq_enable(void)
> 71{
> 72 arch_local_irq_restore(1);
> 73}
Sigh. I meant the real caller, who's calling local_irq_restore().
-Scott
next prev parent reply other threads:[~2013-05-03 22:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-03 16:11 [PATCH] KVM: PPC: Book3E 64: Fix IRQs warnings and hangs Mihai Caraman
2013-05-03 16:11 ` Mihai Caraman
2013-05-03 16:11 ` Mihai Caraman
2013-05-03 16:24 ` Alexander Graf
2013-05-03 16:24 ` Alexander Graf
2013-05-03 16:24 ` Alexander Graf
2013-05-03 22:03 ` Benjamin Herrenschmidt
2013-05-03 22:03 ` Benjamin Herrenschmidt
2013-05-03 22:03 ` Benjamin Herrenschmidt
2013-05-03 18:04 ` Scott Wood
2013-05-03 18:04 ` Scott Wood
2013-05-03 18:04 ` Scott Wood
2013-05-03 20:01 ` Caraman Mihai Claudiu-B02008
2013-05-03 20:01 ` Caraman Mihai Claudiu-B02008
2013-05-03 20:01 ` Caraman Mihai Claudiu-B02008
2013-05-03 20:15 ` Scott Wood
2013-05-03 20:15 ` Scott Wood
2013-05-03 20:15 ` Scott Wood
2013-05-03 20:56 ` Caraman Mihai Claudiu-B02008
2013-05-03 20:56 ` Caraman Mihai Claudiu-B02008
2013-05-03 20:56 ` Caraman Mihai Claudiu-B02008
2013-05-03 22:06 ` Scott Wood [this message]
2013-05-03 22:06 ` Scott Wood
2013-05-03 22:06 ` Scott Wood
2013-05-03 22:59 ` Caraman Mihai Claudiu-B02008
2013-05-03 22:59 ` Caraman Mihai Claudiu-B02008
2013-05-03 22:59 ` Caraman Mihai Claudiu-B02008
2013-05-03 23:30 ` Scott Wood
2013-05-03 23:30 ` Scott Wood
2013-05-03 23:30 ` Scott Wood
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=1367618808.19391.11@snotra \
--to=scottwood@freescale.com \
--cc=B02008@freescale.com \
--cc=B07421@freescale.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.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.