diff for duplicates of <1372871232.8183.131@snotra> diff --git a/a/1.txt b/N1/1.txt index 137ce90..a89af1e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,7 +1,7 @@ On 07/03/2013 10:11:50 AM, Alexander Graf wrote: -> +>=20 > On 03.07.2013, at 15:55, Caraman Mihai Claudiu-B02008 wrote: -> +>=20 > >> -----Original Message----- > >> From: Alexander Graf [mailto:agraf@suse.de] > >> Sent: Wednesday, July 03, 2013 4:45 PM @@ -13,32 +13,32 @@ On 07/03/2013 10:11:50 AM, Alexander Graf wrote: > >> > >> On 03.07.2013, at 14:42, Mihai Caraman wrote: > >> -> >>> Increase FPU laziness by calling kvmppc_load_guest_fp() just +> >>> Increase FPU laziness by calling kvmppc_load_guest_fp() just =20 > before -> >>> returning to guest instead of each sched in. Without this +> >>> returning to guest instead of each sched in. Without this =20 > improvement > >>> an interrupt may also claim floting point corrupting guest state. > >> -> >> Not sure I follow. Could you please describe exactly what's +> >> Not sure I follow. Could you please describe exactly what's =20 > happening? > > -> > This was already discussed on the list, I will forward you the +> > This was already discussed on the list, I will forward you the =20 > thread. -> -> The only thing I've seen in that thread was some pathetic theoretical -> case where an interrupt handler would enable fp and clobber state +>=20 +> The only thing I've seen in that thread was some pathetic theoretical =20 +> case where an interrupt handler would enable fp and clobber state =20 > carelessly. That's not something I'm worried about. -On x86 floating point registers can be used for memcpy(), which can be -used in interrupt handlers. Just because it doesn't happen on PPC -today doesn't make it a "pathetic theoretical case" that we should -ignore and leave a landmine buried in the KVM code. Even power7 is -using something similar for copyuser (which isn't called from interrupt +On x86 floating point registers can be used for memcpy(), which can be =20 +used in interrupt handlers. Just because it doesn't happen on PPC =20 +today doesn't make it a "pathetic theoretical case" that we should =20 +ignore and leave a landmine buried in the KVM code. Even power7 is =20 +using something similar for copyuser (which isn't called from interrupt =20 context, but it's not a huge leap from that to doing it in memcpy). -It also doesn't seem *that* farfetched that some driver for unusual -hardware could decide it needs FP in its interrupt handler, and call -the function that is specifically meant to ensure that. It's frowned +It also doesn't seem *that* farfetched that some driver for unusual =20 +hardware could decide it needs FP in its interrupt handler, and call =20 +the function that is specifically meant to ensure that. It's frowned =20 upon, but that doesn't mean nobody will ever do it. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index ce103a4..f0f50d3 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,18 +1,18 @@ "ref\0C4820C32-33E6-4E34-A24C-C49BD7CC8307@suse.de\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 3/6] KVM: PPC: Book3E: Increase FPU laziness\0" - "Date\0Wed, 03 Jul 2013 17:07:12 +0000\0" + "Date\0Wed, 3 Jul 2013 12:07:12 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>" - kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> kvm@vger.kernel.org <kvm@vger.kernel.org> - " linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>\0" + " kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org>\0" "\00:1\0" "b\0" "On 07/03/2013 10:11:50 AM, Alexander Graf wrote:\n" - "> \n" + ">=20\n" "> On 03.07.2013, at 15:55, Caraman Mihai Claudiu-B02008 wrote:\n" - "> \n" + ">=20\n" "> >> -----Original Message-----\n" "> >> From: Alexander Graf [mailto:agraf@suse.de]\n" "> >> Sent: Wednesday, July 03, 2013 4:45 PM\n" @@ -24,34 +24,34 @@ "> >>\n" "> >> On 03.07.2013, at 14:42, Mihai Caraman wrote:\n" "> >>\n" - "> >>> Increase FPU laziness by calling kvmppc_load_guest_fp() just \n" + "> >>> Increase FPU laziness by calling kvmppc_load_guest_fp() just =20\n" "> before\n" - "> >>> returning to guest instead of each sched in. Without this \n" + "> >>> returning to guest instead of each sched in. Without this =20\n" "> improvement\n" "> >>> an interrupt may also claim floting point corrupting guest state.\n" "> >>\n" - "> >> Not sure I follow. Could you please describe exactly what's \n" + "> >> Not sure I follow. Could you please describe exactly what's =20\n" "> happening?\n" "> >\n" - "> > This was already discussed on the list, I will forward you the \n" + "> > This was already discussed on the list, I will forward you the =20\n" "> thread.\n" - "> \n" - "> The only thing I've seen in that thread was some pathetic theoretical \n" - "> case where an interrupt handler would enable fp and clobber state \n" + ">=20\n" + "> The only thing I've seen in that thread was some pathetic theoretical =20\n" + "> case where an interrupt handler would enable fp and clobber state =20\n" "> carelessly. That's not something I'm worried about.\n" "\n" - "On x86 floating point registers can be used for memcpy(), which can be \n" - "used in interrupt handlers. Just because it doesn't happen on PPC \n" - "today doesn't make it a \"pathetic theoretical case\" that we should \n" - "ignore and leave a landmine buried in the KVM code. Even power7 is \n" - "using something similar for copyuser (which isn't called from interrupt \n" + "On x86 floating point registers can be used for memcpy(), which can be =20\n" + "used in interrupt handlers. Just because it doesn't happen on PPC =20\n" + "today doesn't make it a \"pathetic theoretical case\" that we should =20\n" + "ignore and leave a landmine buried in the KVM code. Even power7 is =20\n" + "using something similar for copyuser (which isn't called from interrupt =20\n" "context, but it's not a huge leap from that to doing it in memcpy).\n" "\n" - "It also doesn't seem *that* farfetched that some driver for unusual \n" - "hardware could decide it needs FP in its interrupt handler, and call \n" - "the function that is specifically meant to ensure that. It's frowned \n" + "It also doesn't seem *that* farfetched that some driver for unusual =20\n" + "hardware could decide it needs FP in its interrupt handler, and call =20\n" + "the function that is specifically meant to ensure that. It's frowned =20\n" "upon, but that doesn't mean nobody will ever do it.\n" "\n" - -Scott + -Scott= -5351d53b96d59414efee53970c264d707f1841bedd0765c307d6d9982aa455cb +7cf3c6f4a666e8f2fb19ff70aad9c7517f735c22540f7e291fbe0c77b844bee3
diff --git a/a/content_digest b/N2/content_digest index ce103a4..44d28a2 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,7 +1,7 @@ "ref\0C4820C32-33E6-4E34-A24C-C49BD7CC8307@suse.de\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 3/6] KVM: PPC: Book3E: Increase FPU laziness\0" - "Date\0Wed, 03 Jul 2013 17:07:12 +0000\0" + "Date\0Wed, 3 Jul 2013 12:07:12 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>" kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org> @@ -54,4 +54,4 @@ "\n" -Scott -5351d53b96d59414efee53970c264d707f1841bedd0765c307d6d9982aa455cb +12c43a8b8a147b3f4a2afdbe727c2f77e448b5ec8261455a6580cdd70bb2f880
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.