diff for duplicates of <1372871854.8183.132@snotra> diff --git a/a/1.txt b/N1/1.txt index 5219104..fba0970 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,68 +1,68 @@ On 07/03/2013 11:59:45 AM, Alexander Graf wrote: -> +>=20 > On 03.07.2013, at 17:41, Caraman Mihai Claudiu-B02008 wrote: -> -> >>>>> Increase FPU laziness by calling kvmppc_load_guest_fp() just +>=20 +> >>>>> 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 +> >>>>> an interrupt may also claim floting point corrupting guest =20 > 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 +> >> The only thing I've seen in that thread was some pathetic =20 > theoretical > >> case where an interrupt handler would enable fp and clobber state > >> carelessly. That's not something I'm worried about. > > -> > Neither me though I don't find it pathetic. Please refer it to +> > Neither me though I don't find it pathetic. Please refer it to =20 > Scott. -> -> If from Linux's point of view we look like a user space program with -> active floating point registers, we don't have to worry about this -> case. Kernel code that would clobber that fp state would clobber +>=20 +> If from Linux's point of view we look like a user space program with =20 +> active floating point registers, we don't have to worry about this =20 +> case. Kernel code that would clobber that fp state would clobber =20 > random user space's fp state too. -This patch makes it closer to how it works with a user space program. -Or rather, it reduces the time window when we don't (and can't) act -like a normal userspace program -- and ensures that we have interrupts -disabled during that window. An interrupt can't randomly clobber FP -state; it has to call enable_kernel_fp() just like KVM does. -enable_kernel_fp() clears the userspace MSR_FP to ensure that the state -it saves gets restored before userspace uses it again, but that won't -have any effect on guest execution (especially in HV-mode). Thus -kvmppc_load_guest_fp() needs to be atomic with guest entry. -Conceptually it's like taking an automatic FP unavailable trap when we +This patch makes it closer to how it works with a user space program. =20 +Or rather, it reduces the time window when we don't (and can't) act =20 +like a normal userspace program -- and ensures that we have interrupts =20 +disabled during that window. An interrupt can't randomly clobber FP =20 +state; it has to call enable_kernel_fp() just like KVM does. =20 +enable_kernel_fp() clears the userspace MSR_FP to ensure that the state =20 +it saves gets restored before userspace uses it again, but that won't =20 +have any effect on guest execution (especially in HV-mode). Thus =20 +kvmppc_load_guest_fp() needs to be atomic with guest entry. =20 +Conceptually it's like taking an automatic FP unavailable trap when we =20 enter the guest, since we can't be lazy in HV-mode. -> >> I really don't see where this patch improves anything tbh. It +> >> I really don't see where this patch improves anything tbh. It =20 > certainly > >> makes the code flow more awkward. > > -> > I was pointing you to this: The idea of FPU/AltiVec laziness that +> > I was pointing you to this: The idea of FPU/AltiVec laziness that =20 > the kernel -> > is struggling to achieve is to reduce the number of store/restore +> > is struggling to achieve is to reduce the number of store/restore =20 > operations. -> > Without this improvement we restore the unit each time we are sched +> > Without this improvement we restore the unit each time we are sched =20 > it. If an -> > other process take the ownership of the unit (on SMP it's even +> > other process take the ownership of the unit (on SMP it's even =20 > worse but don't -> > bother with this) the kernel store the unit state to qemu task. +> > bother with this) the kernel store the unit state to qemu task. =20 > This can happen > > multiple times during handle_exit(). > > > > Do you see it now? -> -> Yup. Looks good. The code flow is very hard to follow though - there -> are a lot of implicit assumptions that don't get documented anywhere. -> For example the fact that we rely on giveup_fpu() to remove MSR_FP +>=20 +> Yup. Looks good. The code flow is very hard to follow though - there =20 +> are a lot of implicit assumptions that don't get documented anywhere. =20 +> For example the fact that we rely on giveup_fpu() to remove MSR_FP =20 > from our thread. That's not new to this patch... --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index e387e56..2e750f5 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,81 +1,81 @@ "ref\023C56B31-5145-481E-9877-F1878F66959D@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:17:34 +0000\0" + "Date\0Wed, 3 Jul 2013 12:17:34 -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 11:59:45 AM, Alexander Graf wrote:\n" - "> \n" + ">=20\n" "> On 03.07.2013, at 17:41, Caraman Mihai Claudiu-B02008 wrote:\n" - "> \n" - "> >>>>> Increase FPU laziness by calling kvmppc_load_guest_fp() just \n" + ">=20\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 \n" + "> >>>>> an interrupt may also claim floting point corrupting guest =20\n" "> 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 \n" + "> >> The only thing I've seen in that thread was some pathetic =20\n" "> theoretical\n" "> >> case where an interrupt handler would enable fp and clobber state\n" "> >> carelessly. That's not something I'm worried about.\n" "> >\n" - "> > Neither me though I don't find it pathetic. Please refer it to \n" + "> > Neither me though I don't find it pathetic. Please refer it to =20\n" "> Scott.\n" - "> \n" - "> If from Linux's point of view we look like a user space program with \n" - "> active floating point registers, we don't have to worry about this \n" - "> case. Kernel code that would clobber that fp state would clobber \n" + ">=20\n" + "> If from Linux's point of view we look like a user space program with =20\n" + "> active floating point registers, we don't have to worry about this =20\n" + "> case. Kernel code that would clobber that fp state would clobber =20\n" "> random user space's fp state too.\n" "\n" - "This patch makes it closer to how it works with a user space program. \n" - "Or rather, it reduces the time window when we don't (and can't) act \n" - "like a normal userspace program -- and ensures that we have interrupts \n" - "disabled during that window. An interrupt can't randomly clobber FP \n" - "state; it has to call enable_kernel_fp() just like KVM does. \n" - "enable_kernel_fp() clears the userspace MSR_FP to ensure that the state \n" - "it saves gets restored before userspace uses it again, but that won't \n" - "have any effect on guest execution (especially in HV-mode). Thus \n" - "kvmppc_load_guest_fp() needs to be atomic with guest entry. \n" - "Conceptually it's like taking an automatic FP unavailable trap when we \n" + "This patch makes it closer to how it works with a user space program. =20\n" + "Or rather, it reduces the time window when we don't (and can't) act =20\n" + "like a normal userspace program -- and ensures that we have interrupts =20\n" + "disabled during that window. An interrupt can't randomly clobber FP =20\n" + "state; it has to call enable_kernel_fp() just like KVM does. =20\n" + "enable_kernel_fp() clears the userspace MSR_FP to ensure that the state =20\n" + "it saves gets restored before userspace uses it again, but that won't =20\n" + "have any effect on guest execution (especially in HV-mode). Thus =20\n" + "kvmppc_load_guest_fp() needs to be atomic with guest entry. =20\n" + "Conceptually it's like taking an automatic FP unavailable trap when we =20\n" "enter the guest, since we can't be lazy in HV-mode.\n" "\n" - "> >> I really don't see where this patch improves anything tbh. It \n" + "> >> I really don't see where this patch improves anything tbh. It =20\n" "> certainly\n" "> >> makes the code flow more awkward.\n" "> >\n" - "> > I was pointing you to this: The idea of FPU/AltiVec laziness that \n" + "> > I was pointing you to this: The idea of FPU/AltiVec laziness that =20\n" "> the kernel\n" - "> > is struggling to achieve is to reduce the number of store/restore \n" + "> > is struggling to achieve is to reduce the number of store/restore =20\n" "> operations.\n" - "> > Without this improvement we restore the unit each time we are sched \n" + "> > Without this improvement we restore the unit each time we are sched =20\n" "> it. If an\n" - "> > other process take the ownership of the unit (on SMP it's even \n" + "> > other process take the ownership of the unit (on SMP it's even =20\n" "> worse but don't\n" - "> > bother with this) the kernel store the unit state to qemu task. \n" + "> > bother with this) the kernel store the unit state to qemu task. =20\n" "> This can happen\n" "> > multiple times during handle_exit().\n" "> >\n" "> > Do you see it now?\n" - "> \n" - "> Yup. Looks good. The code flow is very hard to follow though - there \n" - "> are a lot of implicit assumptions that don't get documented anywhere. \n" - "> For example the fact that we rely on giveup_fpu() to remove MSR_FP \n" + ">=20\n" + "> Yup. Looks good. The code flow is very hard to follow though - there =20\n" + "> are a lot of implicit assumptions that don't get documented anywhere. =20\n" + "> For example the fact that we rely on giveup_fpu() to remove MSR_FP =20\n" "> from our thread.\n" "\n" "That's not new to this patch...\n" "\n" - -Scott + -Scott= -de659b9efa4e58ef12c6e528fe394068acdf23d471542802344fd8e08ccea511 +76e3753cf2272a7285f17a5e7a76e3f5d012d571da8e616de45dd641735abc65
diff --git a/a/content_digest b/N2/content_digest index e387e56..e367cfa 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,7 +1,7 @@ "ref\023C56B31-5145-481E-9877-F1878F66959D@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:17:34 +0000\0" + "Date\0Wed, 3 Jul 2013 12:17:34 -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> @@ -78,4 +78,4 @@ "\n" -Scott -de659b9efa4e58ef12c6e528fe394068acdf23d471542802344fd8e08ccea511 +19b89df45cedac9893b248235ffe684448881ace9f505f07716198c04e35eebf
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.