diff for duplicates of <1367884418.3398.10@snotra> diff --git a/a/1.txt b/N1/1.txt index 90ccfe9..06d1764 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,33 +2,33 @@ On 05/05/2013 04:03:08 PM, Benjamin Herrenschmidt wrote: > On Fri, 2013-05-03 at 18:45 -0500, Scott Wood wrote: > > kvmppc_lazy_ee_enable() was causing interrupts to be soft-enabled > > (albeit hard-disabled) in kvmppc_restart_interrupt(). This led to -> > warnings, and possibly breakage if the interrupt state was later +> > warnings, and possibly breakage if the interrupt state was later =20 > saved > > and then restored (leading to interrupts being hard-and-soft enabled > > when they should be at least soft-disabled). > > > > Simply removing kvmppc_lazy_ee_enable() leaves interrupts only -> > soft-disabled when we enter the guest, but they will be +> > soft-disabled when we enter the guest, but they will be =20 > hard-disabled -> > when we exit the guest -- without PACA_IRQ_HARD_DIS ever being set, +> > when we exit the guest -- without PACA_IRQ_HARD_DIS ever being set, =20 > so > > the local_irq_enable() fails to hard-enable. > > -> > While we could just set PACA_IRQ_HARD_DIS after an exit to +> > While we could just set PACA_IRQ_HARD_DIS after an exit to =20 > compensate, -> > instead hard-disable interrupts before entering the guest. This +> > instead hard-disable interrupts before entering the guest. This =20 > way, > > we won't have to worry about interactions if we take an interrupt > > during the guest entry code. While I don't see any obvious > > interactions, it could change in the future (e.g. it would be bad if -> > the non-hv code were used on 64-bit or if 32-bit guest lazy +> > the non-hv code were used on 64-bit or if 32-bit guest lazy =20 > interrupt > > disabling, since the non-hv code changes IVPR among other things). -> -> Shouldn't the interrupts be marked soft-enabled (even if hard +>=20 +> Shouldn't the interrupts be marked soft-enabled (even if hard =20 > disabled) > when entering the guest ? -> +>=20 > Ie. The last stage of entry will hard enable, so they should be > soft-enabled too... if not, latency trackers will consider the whole > guest periods as "interrupt disabled"... @@ -38,30 +38,30 @@ OK... I guess we already have that problem on 32-bit as well? > Now, kvmppc_lazy_ee_enable() seems to be clearly bogus to me. It will > unconditionally set soft_enabled and clear irq_happened from a > soft-disabled state, thus potentially losing a pending event. -> +>=20 > Book3S "HV" seems to be keeping interrupts fully enabled all the way -> until the asm hard disables, which would be fine except that I'm +> until the asm hard disables, which would be fine except that I'm =20 > worried > we are racy vs. need_resched & signals. -> +>=20 > One thing you may be able to do is call prep_irq_for_idle(). This will > tell you if something happened, giving you a chance to abort/re-enable > before you go the guest. -As long as we go straight from IRQs fully enabled to hard-disabled, -before we check for signals and such, I don't think we need that (and +As long as we go straight from IRQs fully enabled to hard-disabled, =20 +before we check for signals and such, I don't think we need that (and =20 using it would raise the question of what to do on 32-bit). -What if we just take this patch, and add trace_hardirqs_on() just -before entering the guest? This would be similar to what the 32-bit -non-KVM exception return code does (except it would be in C code). -Perhaps we could set soft_enabled as well, but then we'd have to clear -it again before calling kvmppc_restart_interrupt() -- since the KVM -exception handlers don't actually care about soft_enabled (it would +What if we just take this patch, and add trace_hardirqs_on() just =20 +before entering the guest? This would be similar to what the 32-bit =20 +non-KVM exception return code does (except it would be in C code). =20 +Perhaps we could set soft_enabled as well, but then we'd have to clear =20 +it again before calling kvmppc_restart_interrupt() -- since the KVM =20 +exception handlers don't actually care about soft_enabled (it would =20 just be for consistency), I'd rather just leave soft_enabled off. -We also don't want PACA_IRQ_HARD_DIS to be cleared the way -prep_irq_for_idle() does, because that's what lets the +We also don't want PACA_IRQ_HARD_DIS to be cleared the way =20 +prep_irq_for_idle() does, because that's what lets the =20 local_irq_enable() do the hard-enabling after we exit the guest. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index d728b19..5084485 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,7 +1,7 @@ "ref\01367787788.11982.58.camel@pasglop\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH] kvm/ppc/booke64: Hard disable interrupts when entering the guest\0" - "Date\0Mon, 06 May 2013 23:53:38 +0000\0" + "Date\0Mon, 6 May 2013 18:53:38 -0500\0" "To\0Benjamin Herrenschmidt <benh@kernel.crashing.org>\0" "Cc\0kvm@vger.kernel.org" Alexander Graf <agraf@suse.de> @@ -15,33 +15,33 @@ "> On Fri, 2013-05-03 at 18:45 -0500, Scott Wood wrote:\n" "> > kvmppc_lazy_ee_enable() was causing interrupts to be soft-enabled\n" "> > (albeit hard-disabled) in kvmppc_restart_interrupt(). This led to\n" - "> > warnings, and possibly breakage if the interrupt state was later \n" + "> > warnings, and possibly breakage if the interrupt state was later =20\n" "> saved\n" "> > and then restored (leading to interrupts being hard-and-soft enabled\n" "> > when they should be at least soft-disabled).\n" "> >\n" "> > Simply removing kvmppc_lazy_ee_enable() leaves interrupts only\n" - "> > soft-disabled when we enter the guest, but they will be \n" + "> > soft-disabled when we enter the guest, but they will be =20\n" "> hard-disabled\n" - "> > when we exit the guest -- without PACA_IRQ_HARD_DIS ever being set, \n" + "> > when we exit the guest -- without PACA_IRQ_HARD_DIS ever being set, =20\n" "> so\n" "> > the local_irq_enable() fails to hard-enable.\n" "> >\n" - "> > While we could just set PACA_IRQ_HARD_DIS after an exit to \n" + "> > While we could just set PACA_IRQ_HARD_DIS after an exit to =20\n" "> compensate,\n" - "> > instead hard-disable interrupts before entering the guest. This \n" + "> > instead hard-disable interrupts before entering the guest. This =20\n" "> way,\n" "> > we won't have to worry about interactions if we take an interrupt\n" "> > during the guest entry code. While I don't see any obvious\n" "> > interactions, it could change in the future (e.g. it would be bad if\n" - "> > the non-hv code were used on 64-bit or if 32-bit guest lazy \n" + "> > the non-hv code were used on 64-bit or if 32-bit guest lazy =20\n" "> interrupt\n" "> > disabling, since the non-hv code changes IVPR among other things).\n" - "> \n" - "> Shouldn't the interrupts be marked soft-enabled (even if hard \n" + ">=20\n" + "> Shouldn't the interrupts be marked soft-enabled (even if hard =20\n" "> disabled)\n" "> when entering the guest ?\n" - "> \n" + ">=20\n" "> Ie. The last stage of entry will hard enable, so they should be\n" "> soft-enabled too... if not, latency trackers will consider the whole\n" "> guest periods as \"interrupt disabled\"...\n" @@ -51,32 +51,32 @@ "> Now, kvmppc_lazy_ee_enable() seems to be clearly bogus to me. It will\n" "> unconditionally set soft_enabled and clear irq_happened from a\n" "> soft-disabled state, thus potentially losing a pending event.\n" - "> \n" + ">=20\n" "> Book3S \"HV\" seems to be keeping interrupts fully enabled all the way\n" - "> until the asm hard disables, which would be fine except that I'm \n" + "> until the asm hard disables, which would be fine except that I'm =20\n" "> worried\n" "> we are racy vs. need_resched & signals.\n" - "> \n" + ">=20\n" "> One thing you may be able to do is call prep_irq_for_idle(). This will\n" "> tell you if something happened, giving you a chance to abort/re-enable\n" "> before you go the guest.\n" "\n" - "As long as we go straight from IRQs fully enabled to hard-disabled, \n" - "before we check for signals and such, I don't think we need that (and \n" + "As long as we go straight from IRQs fully enabled to hard-disabled, =20\n" + "before we check for signals and such, I don't think we need that (and =20\n" "using it would raise the question of what to do on 32-bit).\n" "\n" - "What if we just take this patch, and add trace_hardirqs_on() just \n" - "before entering the guest? This would be similar to what the 32-bit \n" - "non-KVM exception return code does (except it would be in C code). \n" - "Perhaps we could set soft_enabled as well, but then we'd have to clear \n" - "it again before calling kvmppc_restart_interrupt() -- since the KVM \n" - "exception handlers don't actually care about soft_enabled (it would \n" + "What if we just take this patch, and add trace_hardirqs_on() just =20\n" + "before entering the guest? This would be similar to what the 32-bit =20\n" + "non-KVM exception return code does (except it would be in C code). =20\n" + "Perhaps we could set soft_enabled as well, but then we'd have to clear =20\n" + "it again before calling kvmppc_restart_interrupt() -- since the KVM =20\n" + "exception handlers don't actually care about soft_enabled (it would =20\n" "just be for consistency), I'd rather just leave soft_enabled off.\n" "\n" - "We also don't want PACA_IRQ_HARD_DIS to be cleared the way \n" - "prep_irq_for_idle() does, because that's what lets the \n" + "We also don't want PACA_IRQ_HARD_DIS to be cleared the way =20\n" + "prep_irq_for_idle() does, because that's what lets the =20\n" "local_irq_enable() do the hard-enabling after we exit the guest.\n" "\n" - -Scott + -Scott= -c3501250246315b712479d6f517fbd1259152745c09fdd7424e848b454775db1 +af5e0492290760e643227a623c0014077818e053a398b797869c025ca5bf893d
diff --git a/a/content_digest b/N2/content_digest index d728b19..9d6704d 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,7 +1,7 @@ "ref\01367787788.11982.58.camel@pasglop\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH] kvm/ppc/booke64: Hard disable interrupts when entering the guest\0" - "Date\0Mon, 06 May 2013 23:53:38 +0000\0" + "Date\0Mon, 6 May 2013 18:53:38 -0500\0" "To\0Benjamin Herrenschmidt <benh@kernel.crashing.org>\0" "Cc\0kvm@vger.kernel.org" Alexander Graf <agraf@suse.de> @@ -79,4 +79,4 @@ "\n" -Scott -c3501250246315b712479d6f517fbd1259152745c09fdd7424e848b454775db1 +1339ddfa77757092f6f2171b9c58cbabcb22dec45197723c6a9e728a27370bf2
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.