diff for duplicates of <1367895926.3398.14@snotra> diff --git a/a/1.txt b/N1/1.txt index 0c747f4..ecb971f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,28 +2,28 @@ On 05/06/2013 07:03:14 PM, Benjamin Herrenschmidt wrote: > On Mon, 2013-05-06 at 18:53 -0500, Scott Wood wrote: > > > > > Ie. The last stage of entry will hard enable, so they should be -> > > soft-enabled too... if not, latency trackers will consider the +> > > soft-enabled too... if not, latency trackers will consider the =20 > whole > > > guest periods as "interrupt disabled"... > > > > OK... I guess we already have that problem on 32-bit as well? -> -> 32-bit doesn't do lazy disable, so the situation is a lot easier +>=20 +> 32-bit doesn't do lazy disable, so the situation is a lot easier =20 > there. -Right, but it still currently enters the guest with interrupts marked +Right, but it still currently enters the guest with interrupts marked =20 as disabled, so we'd have the same latency tracker issue. > Another problem is that hard_irq_disable() doesn't call > trace_hardirqs_off()... We might want to fix that: -> +>=20 > static inline void hard_irq_disable(void) > { > __hard_irq_disable(); > if (get_paca()->soft_enabled) > trace_hardirqs_off(); -> get_paca()->soft_enabled = 0; -> get_paca()->irq_happened |= PACA_IRQ_HARD_DIS; +> get_paca()->soft_enabled =3D 0; +> get_paca()->irq_happened |=3D PACA_IRQ_HARD_DIS; > } Is it possible there are places that assume the current behavior? @@ -31,19 +31,19 @@ Is it possible there are places that assume the current behavior? > > 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 > > local_irq_enable() do the hard-enabling after we exit the guest. -> -> Then set it again. Don't leave the kernel in a state where +>=20 +> Then set it again. Don't leave the kernel in a state where =20 > soft_enabled > is 1 and irq_happened is non-zero. It might work in the specific KVM > case we are looking at now because we know we are coming back via KVM -> exit and putting things right again but it's fragile, somebody will +> exit and putting things right again but it's fragile, somebody will =20 > come > back and break it, etc... -KVM is a pretty special case -- at least on booke, it's required that -all exits from guest state go through the KVM exception code. I think -it's less likely that that changes, than something breaks in the code -to fix up lazy ee state (especially since we've already seen the latter +KVM is a pretty special case -- at least on booke, it's required that =20 +all exits from guest state go through the KVM exception code. I think =20 +it's less likely that that changes, than something breaks in the code =20 +to fix up lazy ee state (especially since we've already seen the latter =20 happen). I'll give it a shot, though. @@ -52,10 +52,10 @@ I'll give it a shot, though. > state adjustement. The cost of a couple of byte stores is negligible, > I'd rather you make sure everything remains in sync at all times. -My concern was mainly about complexity -- it seemed simpler to just say -that the during guest execution, CPU is in a special state that is not -visible to anything that cares about lazy EE. The fact that EE can -actually be *off* and we still take the interrupt supports its +My concern was mainly about complexity -- it seemed simpler to just say =20 +that the during guest execution, CPU is in a special state that is not =20 +visible to anything that cares about lazy EE. The fact that EE can =20 +actually be *off* and we still take the interrupt supports its =20 specialness. :-) --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index f5c2273..05e3368 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,42 +1,42 @@ "ref\01367884994.29496.28.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\0Tue, 07 May 2013 03:05:26 +0000\0" + "Date\0Mon, 6 May 2013 22:05:26 -0500\0" "To\0Benjamin Herrenschmidt <benh@kernel.crashing.org>\0" - "Cc\0Alexander Graf <agraf@suse.de>" - Mihai Caraman <mihai.caraman@freescale.com> - linuxppc-dev@lists.ozlabs.org - kvm@vger.kernel.org + "Cc\0kvm@vger.kernel.org" + Alexander Graf <agraf@suse.de> kvm-ppc@vger.kernel.org - " Paul Mackerras <paulus@au1.ibm.com>\0" + Mihai Caraman <mihai.caraman@freescale.com> + Paul Mackerras <paulus@au1.ibm.com> + " linuxppc-dev@lists.ozlabs.org\0" "\00:1\0" "b\0" "On 05/06/2013 07:03:14 PM, Benjamin Herrenschmidt wrote:\n" "> On Mon, 2013-05-06 at 18:53 -0500, Scott Wood wrote:\n" "> >\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 \n" + "> > > soft-enabled too... if not, latency trackers will consider the =20\n" "> whole\n" "> > > guest periods as \"interrupt disabled\"...\n" "> >\n" "> > OK... I guess we already have that problem on 32-bit as well?\n" - "> \n" - "> 32-bit doesn't do lazy disable, so the situation is a lot easier \n" + ">=20\n" + "> 32-bit doesn't do lazy disable, so the situation is a lot easier =20\n" "> there.\n" "\n" - "Right, but it still currently enters the guest with interrupts marked \n" + "Right, but it still currently enters the guest with interrupts marked =20\n" "as disabled, so we'd have the same latency tracker issue.\n" "\n" "> Another problem is that hard_irq_disable() doesn't call\n" "> trace_hardirqs_off()... We might want to fix that:\n" - "> \n" + ">=20\n" "> static inline void hard_irq_disable(void)\n" "> {\n" "> \t__hard_irq_disable();\n" "> \tif (get_paca()->soft_enabled)\n" "> \t\ttrace_hardirqs_off();\n" - "> \tget_paca()->soft_enabled = 0;\n" - "> \tget_paca()->irq_happened |= PACA_IRQ_HARD_DIS;\n" + "> \tget_paca()->soft_enabled =3D 0;\n" + "> \tget_paca()->irq_happened |=3D PACA_IRQ_HARD_DIS;\n" "> }\n" "\n" "Is it possible there are places that assume the current behavior?\n" @@ -44,19 +44,19 @@ "> > 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" "> > local_irq_enable() do the hard-enabling after we exit the guest.\n" - "> \n" - "> Then set it again. Don't leave the kernel in a state where \n" + ">=20\n" + "> Then set it again. Don't leave the kernel in a state where =20\n" "> soft_enabled\n" "> is 1 and irq_happened is non-zero. It might work in the specific KVM\n" "> case we are looking at now because we know we are coming back via KVM\n" - "> exit and putting things right again but it's fragile, somebody will \n" + "> exit and putting things right again but it's fragile, somebody will =20\n" "> come\n" "> back and break it, etc...\n" "\n" - "KVM is a pretty special case -- at least on booke, it's required that \n" - "all exits from guest state go through the KVM exception code. I think \n" - "it's less likely that that changes, than something breaks in the code \n" - "to fix up lazy ee state (especially since we've already seen the latter \n" + "KVM is a pretty special case -- at least on booke, it's required that =20\n" + "all exits from guest state go through the KVM exception code. I think =20\n" + "it's less likely that that changes, than something breaks in the code =20\n" + "to fix up lazy ee state (especially since we've already seen the latter =20\n" "happen).\n" "\n" "I'll give it a shot, though.\n" @@ -65,12 +65,12 @@ "> state adjustement. The cost of a couple of byte stores is negligible,\n" "> I'd rather you make sure everything remains in sync at all times.\n" "\n" - "My concern was mainly about complexity -- it seemed simpler to just say \n" - "that the during guest execution, CPU is in a special state that is not \n" - "visible to anything that cares about lazy EE. The fact that EE can \n" - "actually be *off* and we still take the interrupt supports its \n" + "My concern was mainly about complexity -- it seemed simpler to just say =20\n" + "that the during guest execution, CPU is in a special state that is not =20\n" + "visible to anything that cares about lazy EE. The fact that EE can =20\n" + "actually be *off* and we still take the interrupt supports its =20\n" "specialness. :-)\n" "\n" - -Scott + -Scott= -403c5361b233315ed153e098d39d0f65b0d51888fc692ac16fd860d908b7357d +115ff5ce47c490c1cd6b0eef50340b95cfbd6e793f45e19a3319b72c2fa6092e
diff --git a/a/content_digest b/N2/content_digest index f5c2273..ddf64a2 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,13 +1,13 @@ "ref\01367884994.29496.28.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\0Tue, 07 May 2013 03:05:26 +0000\0" + "Date\0Mon, 6 May 2013 22:05:26 -0500\0" "To\0Benjamin Herrenschmidt <benh@kernel.crashing.org>\0" "Cc\0Alexander Graf <agraf@suse.de>" Mihai Caraman <mihai.caraman@freescale.com> - linuxppc-dev@lists.ozlabs.org - kvm@vger.kernel.org - kvm-ppc@vger.kernel.org + <linuxppc-dev@lists.ozlabs.org> + <kvm@vger.kernel.org> + <kvm-ppc@vger.kernel.org> " Paul Mackerras <paulus@au1.ibm.com>\0" "\00:1\0" "b\0" @@ -73,4 +73,4 @@ "\n" -Scott -403c5361b233315ed153e098d39d0f65b0d51888fc692ac16fd860d908b7357d +ac2db3bc342a6437508ebd8b38c2e4e248629c61a036ff1acba5bf91608f9334
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.