diff for duplicates of <1424667110.16027.6.camel@neuling.org> diff --git a/a/1.txt b/N1/1.txt index 5214356..c385d85 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,7 +3,7 @@ Uli, Sorry for the slow response. > Michael Neuling <mikey@neuling.org> wrote on 28.01.2015 05:28:09: ->=20 +> > > Sorry, I'm rethinking this as we didn't consider user suspended > > transactions. > > @@ -11,13 +11,13 @@ Sorry for the slow response. > > transactions the running values are the ones you want to modify since > > that is where you'll end up restarting from. The hardware will only > > abort/rollback once a tresume is encountered. ->=20 +> > OK, I see. I hadn't really looked into suspended transactions before ... > > > So we could do what you're talking about for normal transactions and > > then switch them for suspended transactions. But this just seems to be > > making the kernel interface overly complicated. ->=20 +> > Agreed. Given that there seems to be an inevitable difference in how > transactions are seen by the debugger between Power and z (there are > no suspended transactions on z), I guess it makes more sense to have @@ -29,7 +29,7 @@ Sorry for the slow response. > > modify. The kernel always provides the "normal" set as running and the > > new set as check pointed. GDB then has to check the MSR to work out > > what it wants to modify. ->=20 +> > So I'm thinking how this all would work out for the case of GDB wanting > to call an inferior function while the process is stopped within a > transaction (in either transactional or suspended state). @@ -37,7 +37,7 @@ Sorry for the slow response. Should this inferior function be run in the current mode of the processor? ie if the process is currently transactional and the transaction aborts, should we be able to see any global state change -because of an inferior function being run in GDB? =20 +because of an inferior function being run in GDB? Also, if you modify the stack in suspend mode, that'll be persistent. So it's possible that you could corrupt your stack if you abort. For @@ -49,7 +49,7 @@ abort and not corrupt your stack. I think what you're proposing with running the inferior function in suspend mode may end up corrupting the stack in this way. You'd need to be really careful to make sure the inferior function is run on the stack -pointer of the checkpointed registers. =20 +pointer of the checkpointed registers. We do something like this in the kernel when laying out a signal frame on the user stack when the user is transactional. We lay it out on the @@ -83,7 +83,7 @@ I think so. > (Hmm. Maybe GDB would also have to set cr0 or something?) OK, but do we want the inferior function to be run non-transactionally? -Should it changes be seen after the transaction aborts? =20 +Should it changes be seen after the transaction aborts? > Is it possible for GDB to change the state (transactional vs. > suspended) where the kernel ought to let the application continue in? @@ -92,7 +92,7 @@ Should it changes be seen after the transaction aborts? =20 Yes, you can change the MSR to change the TM mode. > If so, there would be other options to handle this: ->=20 +> > (A') In the transactional state, GDB could set the MSR to suspended, > and modify the "normal" register set. The inferior function would > execute in the suspended state as in (A) above. Upon return, GDB @@ -105,7 +105,7 @@ effects even if the transaction aborts. Is that what we want? Can we say to users that the inferior function is actually be run after the transaction aborts? -Also, we need to be careful with the stack. =20 +Also, we need to be careful with the stack. > (B') In the suspended state, GDB could set the MSR to transactional, > and modify the "checkpointed" register set. Once the kernel resumes @@ -122,7 +122,7 @@ OK. > advantage that the inferior function always executes in the same > state (suspended), while leaving information about the interrupted > transaction visible. ->=20 +> > Using the combination of (B)+(B') would be a bit more difficult > to implement (but certainly feasible), and would have the advantage > that the inferior function always executes in nontransactional state @@ -145,11 +145,11 @@ Yep. > > values when it's a user suspended transaction. So I don't agree with > > this any more in the case of user suspended transaction. We need to be > > able to modify both sets of registers. ->=20 +> > So I guess the kernel, on resuming the application, first loads the > checkpointed register set into normal registers, issues the trechkpt > instruction to move them to the checkpointed register, and then loads -> the normal register set, before returning to user space? =20 +> the normal register set, before returning to user space? Correct. diff --git a/a/content_digest b/N1/content_digest index 33c91a5..b042f7d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -12,25 +12,26 @@ "Subject\0Re: [V6,1/9] elf: Add new powerpc specifc core note sections\0" "Date\0Mon, 23 Feb 2015 15:51:50 +1100\0" "To\0Ulrich Weigand <Ulrich.Weigand@de.ibm.com>\0" - "Cc\0shuahkh@osg.samsung.com" - james.hogan@imgtec.com + "Cc\0akpm@linux-foundation.org" avagin@openvz.org - Paul.Clothier@imgtec.com - peterz@infradead.org - linux-kernel@vger.kernel.org + davej@redhat.com davem@davemloft.net dhowells@redhat.com - linuxppc-dev@ozlabs.org + Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> + james.hogan@imgtec.com + Anshuman Khandual <khandual@linux.vnet.ibm.com> kirjanov@gmail.com - tglx@linutronix.de + linux-kernel@vger.kernel.org + linuxppc-dev@ozlabs.org + Michael Ellerman <mpe@ellerman.id.au> oleg@redhat.com - sukadev@linux.vnet.ibm.com - davej@redhat.com - akpm@linux-foundation.org palves@redhat.com - Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> + Paul.Clothier@imgtec.com + peterz@infradead.org sam.bobroff@au1.ibm.com - " Anshuman Khandual <khandual@linux.vnet.ibm.com>\0" + shuahkh@osg.samsung.com + sukadev@linux.vnet.ibm.com + " tglx@linutronix.de\0" "\00:1\0" "b\0" "Uli,\n" @@ -38,7 +39,7 @@ "Sorry for the slow response.\n" "\n" "> Michael Neuling <mikey@neuling.org> wrote on 28.01.2015 05:28:09:\n" - ">=20\n" + "> \n" "> > Sorry, I'm rethinking this as we didn't consider user suspended\n" "> > transactions.\n" "> >\n" @@ -46,13 +47,13 @@ "> > transactions the running values are the ones you want to modify since\n" "> > that is where you'll end up restarting from. The hardware will only\n" "> > abort/rollback once a tresume is encountered.\n" - ">=20\n" + "> \n" "> OK, I see. I hadn't really looked into suspended transactions before ...\n" ">\n" "> > So we could do what you're talking about for normal transactions and\n" "> > then switch them for suspended transactions. But this just seems to be\n" "> > making the kernel interface overly complicated.\n" - ">=20\n" + "> \n" "> Agreed. Given that there seems to be an inevitable difference in how\n" "> transactions are seen by the debugger between Power and z (there are\n" "> no suspended transactions on z), I guess it makes more sense to have\n" @@ -64,7 +65,7 @@ "> > modify. The kernel always provides the \"normal\" set as running and the\n" "> > new set as check pointed. GDB then has to check the MSR to work out\n" "> > what it wants to modify.\n" - ">=20\n" + "> \n" "> So I'm thinking how this all would work out for the case of GDB wanting\n" "> to call an inferior function while the process is stopped within a\n" "> transaction (in either transactional or suspended state).\n" @@ -72,7 +73,7 @@ "Should this inferior function be run in the current mode of the\n" "processor? ie if the process is currently transactional and the\n" "transaction aborts, should we be able to see any global state change\n" - "because of an inferior function being run in GDB? =20\n" + "because of an inferior function being run in GDB? \n" "\n" "Also, if you modify the stack in suspend mode, that'll be persistent.\n" "So it's possible that you could corrupt your stack if you abort. For\n" @@ -84,7 +85,7 @@ "I think what you're proposing with running the inferior function in\n" "suspend mode may end up corrupting the stack in this way. You'd need to\n" "be really careful to make sure the inferior function is run on the stack\n" - "pointer of the checkpointed registers. =20\n" + "pointer of the checkpointed registers. \n" "\n" "We do something like this in the kernel when laying out a signal frame\n" "on the user stack when the user is transactional. We lay it out on the\n" @@ -118,7 +119,7 @@ "> (Hmm. Maybe GDB would also have to set cr0 or something?)\n" "\n" "OK, but do we want the inferior function to be run non-transactionally?\n" - "Should it changes be seen after the transaction aborts? =20\n" + "Should it changes be seen after the transaction aborts? \n" "\n" "> Is it possible for GDB to change the state (transactional vs.\n" "> suspended) where the kernel ought to let the application continue in?\n" @@ -127,7 +128,7 @@ "Yes, you can change the MSR to change the TM mode.\n" "\n" "> If so, there would be other options to handle this:\n" - ">=20\n" + "> \n" "> (A') In the transactional state, GDB could set the MSR to suspended,\n" "> and modify the \"normal\" register set. The inferior function would\n" "> execute in the suspended state as in (A) above. Upon return, GDB\n" @@ -140,7 +141,7 @@ "say to users that the inferior function is actually be run after the\n" "transaction aborts?\n" "\n" - "Also, we need to be careful with the stack. =20\n" + "Also, we need to be careful with the stack. \n" "\n" "> (B') In the suspended state, GDB could set the MSR to transactional,\n" "> and modify the \"checkpointed\" register set. Once the kernel resumes\n" @@ -157,7 +158,7 @@ "> advantage that the inferior function always executes in the same\n" "> state (suspended), while leaving information about the interrupted\n" "> transaction visible.\n" - ">=20\n" + "> \n" "> Using the combination of (B)+(B') would be a bit more difficult\n" "> to implement (but certainly feasible), and would have the advantage\n" "> that the inferior function always executes in nontransactional state\n" @@ -180,11 +181,11 @@ "> > values when it's a user suspended transaction. So I don't agree with\n" "> > this any more in the case of user suspended transaction. We need to be\n" "> > able to modify both sets of registers.\n" - ">=20\n" + "> \n" "> So I guess the kernel, on resuming the application, first loads the\n" "> checkpointed register set into normal registers, issues the trechkpt\n" "> instruction to move them to the checkpointed register, and then loads\n" - "> the normal register set, before returning to user space? =20\n" + "> the normal register set, before returning to user space? \n" "\n" "Correct.\n" "\n" @@ -200,4 +201,4 @@ "Regards,\n" Mikey -e09c9d502afd56dcad87f7b135321baa3688dfcc39e75aebc6688aa61679760f +057e4b50725b0d27f0cb45c6c6d4943eb2898a40287a1c27b39adba82d159886
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.