diff for duplicates of <1369870703.18630.49@snotra> diff --git a/a/1.txt b/N1/1.txt index a4da3e8..2cdeed8 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,38 +1,38 @@ On 05/28/2013 07:41:18 PM, Benjamin Herrenschmidt wrote: > On Tue, 2013-05-28 at 12:41 -0500, Scott Wood wrote: -> -> > I believe Alex is staying far away from e-mail on his vacation. +>=20 +> > I believe Alex is staying far away from e-mail on his vacation. =20 > He's > > asked me to fill in for him while he's gone. > > -> > The patch itself seems reasonable (though I don't know much about +> > The patch itself seems reasonable (though I don't know much about =20 > XICS, -> > and do have one question...), but I'll leave it up to +> > and do have one question...), but I'll leave it up to =20 > Gleb/Marcelo/Ben > > if it should go in for 3.10 and via which tree. I understand the -> > desire to not have an incomplete ABI in a released version, but +> > desire to not have an incomplete ABI in a released version, but =20 > Linus > > is already grumbling about how much went into rc3, and you say the > > hcalls aren't currently used... Are they likely to be used in any > > timeframe in which we'd reasonably care about 3.10? -> +>=20 > Yes. I'd like to have them in. Their implementation is actually fairly > trivial and they cannot be emulated by qemu if the rest of the XICS is > in the kernel, so it's a problem. -OK. Does it make more sense for you to take it as Paul suggested, or +OK. Does it make more sense for you to take it as Paul suggested, or =20 for Gleb or Marcelo to pick it up directly? > > > + /* These requests don't have real-mode implementations at > > > present */ > > > + switch (req) { > > > + case H_XIRR_X: -> > > + res = kvmppc_h_xirr(vcpu); +> > > + res =3D kvmppc_h_xirr(vcpu); > > > + kvmppc_set_gpr(vcpu, 4, res); > > > + kvmppc_set_gpr(vcpu, 5, get_tb()); > > > + return rc; > > > + case H_IPOLL: -> > > + rc = kvmppc_h_ipoll(vcpu, kvmppc_get_gpr(vcpu, 4)); +> > > + rc =3D kvmppc_h_ipoll(vcpu, kvmppc_get_gpr(vcpu, 4)); > > > + return rc; > > > + } > > > + @@ -43,36 +43,36 @@ for Gleb or Marcelo to pick it up directly? > > Could you explain what's going on here relative to > > kvmppc_xics_rm_complete()? What does "returning too hard" mean, and > > why must rm_action not be checked for these hcalls? -> +>=20 > This is related to how we handle some hcalls in real mode as a fast -> path. The real-mode stuff cannot handle cases that require for +> path. The real-mode stuff cannot handle cases that require for =20 > example a -> re-emit of the interrupt, a reject, etc... so in some cases, it +> re-emit of the interrupt, a reject, etc... so in some cases, it =20 > returns -> H_TOO_HARD which causes KVM to exit and try to handle the hcall again +> H_TOO_HARD which causes KVM to exit and try to handle the hcall again =20 > in > kernel virtual mode. -> +>=20 > When doing so as the result of a XICS hcall, it sets a bit mask of > "tasks" to handle in virtual mode (because it will have already > partially done the operation, it cannot just re-play the whole hcall). -> -> So when real-mode is supported we must not just call the normal +>=20 +> So when real-mode is supported we must not just call the normal =20 > virtual > mode version of the hcalls, we instead go to kvmppc_xics_rm_complete() > to handle those "tasks". -> +>=20 > However, for those 2 "missing" hcalls, we have no real mode > implementation at all (we didn't bother, we will do that later if > needed, it's purely a performance issue). So we need to fully handle -> them in virtual mode, and we know there will be no "tasks" to handle +> them in virtual mode, and we know there will be no "tasks" to handle =20 > in > rm_complete. -Then rm_action should always be 0 for these hcalls, right? So there's -no correctness reason to keep the hcalls in separate switch -statements. You shave off a few cycles checking rm_action, at the cost -of needing to change kvmppc_xics_hcall() if a real-mode version of +Then rm_action should always be 0 for these hcalls, right? So there's =20 +no correctness reason to keep the hcalls in separate switch =20 +statements. You shave off a few cycles checking rm_action, at the cost =20 +of needing to change kvmppc_xics_hcall() if a real-mode version of =20 these hcalls is ever done. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index 2b953c8..bce72b8 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,52 +1,52 @@ "ref\01369788078.3928.28.camel@pasglop\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH] KVM: PPC: Book3S: Add support for H_IPOLL and H_XIRR_X in XICS emulation\0" - "Date\0Wed, 29 May 2013 23:38:23 +0000\0" + "Date\0Wed, 29 May 2013 18:38:23 -0500\0" "To\0Benjamin Herrenschmidt <benh@kernel.crashing.org>\0" - "Cc\0Paul Mackerras <paulus@samba.org>" + "Cc\0kvm@vger.kernel.org" + Gleb Natapov <gleb@redhat.com> + Marcelo Tosatti <mtosatti@redhat.com> + Alexander Graf <agraf@suse.de> kvm-ppc@vger.kernel.org - kvm@vger.kernel.org linuxppc-dev@ozlabs.org - Alexander Graf <agraf@suse.de> - Gleb Natapov <gleb@redhat.com> - " Marcelo Tosatti <mtosatti@redhat.com>\0" + " Paul Mackerras <paulus@samba.org>\0" "\00:1\0" "b\0" "On 05/28/2013 07:41:18 PM, Benjamin Herrenschmidt wrote:\n" "> On Tue, 2013-05-28 at 12:41 -0500, Scott Wood wrote:\n" - "> \n" - "> > I believe Alex is staying far away from e-mail on his vacation. \n" + ">=20\n" + "> > I believe Alex is staying far away from e-mail on his vacation. =20\n" "> He's\n" "> > asked me to fill in for him while he's gone.\n" "> >\n" - "> > The patch itself seems reasonable (though I don't know much about \n" + "> > The patch itself seems reasonable (though I don't know much about =20\n" "> XICS,\n" - "> > and do have one question...), but I'll leave it up to \n" + "> > and do have one question...), but I'll leave it up to =20\n" "> Gleb/Marcelo/Ben\n" "> > if it should go in for 3.10 and via which tree. I understand the\n" - "> > desire to not have an incomplete ABI in a released version, but \n" + "> > desire to not have an incomplete ABI in a released version, but =20\n" "> Linus\n" "> > is already grumbling about how much went into rc3, and you say the\n" "> > hcalls aren't currently used... Are they likely to be used in any\n" "> > timeframe in which we'd reasonably care about 3.10?\n" - "> \n" + ">=20\n" "> Yes. I'd like to have them in. Their implementation is actually fairly\n" "> trivial and they cannot be emulated by qemu if the rest of the XICS is\n" "> in the kernel, so it's a problem.\n" "\n" - "OK. Does it make more sense for you to take it as Paul suggested, or \n" + "OK. Does it make more sense for you to take it as Paul suggested, or =20\n" "for Gleb or Marcelo to pick it up directly?\n" "\n" "> > > +\t/* These requests don't have real-mode implementations at\n" "> > > present */\n" "> > > +\tswitch (req) {\n" "> > > +\tcase H_XIRR_X:\n" - "> > > +\t\tres = kvmppc_h_xirr(vcpu);\n" + "> > > +\t\tres =3D kvmppc_h_xirr(vcpu);\n" "> > > +\t\tkvmppc_set_gpr(vcpu, 4, res);\n" "> > > +\t\tkvmppc_set_gpr(vcpu, 5, get_tb());\n" "> > > +\t\treturn rc;\n" "> > > +\tcase H_IPOLL:\n" - "> > > +\t\trc = kvmppc_h_ipoll(vcpu, kvmppc_get_gpr(vcpu, 4));\n" + "> > > +\t\trc =3D kvmppc_h_ipoll(vcpu, kvmppc_get_gpr(vcpu, 4));\n" "> > > +\t\treturn rc;\n" "> > > +\t}\n" "> > > +\n" @@ -57,38 +57,38 @@ "> > Could you explain what's going on here relative to\n" "> > kvmppc_xics_rm_complete()? What does \"returning too hard\" mean, and\n" "> > why must rm_action not be checked for these hcalls?\n" - "> \n" + ">=20\n" "> This is related to how we handle some hcalls in real mode as a fast\n" - "> path. The real-mode stuff cannot handle cases that require for \n" + "> path. The real-mode stuff cannot handle cases that require for =20\n" "> example a\n" - "> re-emit of the interrupt, a reject, etc... so in some cases, it \n" + "> re-emit of the interrupt, a reject, etc... so in some cases, it =20\n" "> returns\n" - "> H_TOO_HARD which causes KVM to exit and try to handle the hcall again \n" + "> H_TOO_HARD which causes KVM to exit and try to handle the hcall again =20\n" "> in\n" "> kernel virtual mode.\n" - "> \n" + ">=20\n" "> When doing so as the result of a XICS hcall, it sets a bit mask of\n" "> \"tasks\" to handle in virtual mode (because it will have already\n" "> partially done the operation, it cannot just re-play the whole hcall).\n" - "> \n" - "> So when real-mode is supported we must not just call the normal \n" + ">=20\n" + "> So when real-mode is supported we must not just call the normal =20\n" "> virtual\n" "> mode version of the hcalls, we instead go to kvmppc_xics_rm_complete()\n" "> to handle those \"tasks\".\n" - "> \n" + ">=20\n" "> However, for those 2 \"missing\" hcalls, we have no real mode\n" "> implementation at all (we didn't bother, we will do that later if\n" "> needed, it's purely a performance issue). So we need to fully handle\n" - "> them in virtual mode, and we know there will be no \"tasks\" to handle \n" + "> them in virtual mode, and we know there will be no \"tasks\" to handle =20\n" "> in\n" "> rm_complete.\n" "\n" - "Then rm_action should always be 0 for these hcalls, right? So there's \n" - "no correctness reason to keep the hcalls in separate switch \n" - "statements. You shave off a few cycles checking rm_action, at the cost \n" - "of needing to change kvmppc_xics_hcall() if a real-mode version of \n" + "Then rm_action should always be 0 for these hcalls, right? So there's =20\n" + "no correctness reason to keep the hcalls in separate switch =20\n" + "statements. You shave off a few cycles checking rm_action, at the cost =20\n" + "of needing to change kvmppc_xics_hcall() if a real-mode version of =20\n" "these hcalls is ever done.\n" "\n" - -Scott + -Scott= -88d830f05f8192c8ee7dc65b93307c0fe97d0f1592ccd7f3a40353ebf774bc51 +687ab6e95cde8a0bf5193979ea7e69da7c3a19e6f49a68a17155ffec8eae1126
diff --git a/a/content_digest b/N2/content_digest index 2b953c8..bd88b3f 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,12 +1,12 @@ "ref\01369788078.3928.28.camel@pasglop\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH] KVM: PPC: Book3S: Add support for H_IPOLL and H_XIRR_X in XICS emulation\0" - "Date\0Wed, 29 May 2013 23:38:23 +0000\0" + "Date\0Wed, 29 May 2013 18:38:23 -0500\0" "To\0Benjamin Herrenschmidt <benh@kernel.crashing.org>\0" "Cc\0Paul Mackerras <paulus@samba.org>" - kvm-ppc@vger.kernel.org - kvm@vger.kernel.org - linuxppc-dev@ozlabs.org + <kvm-ppc@vger.kernel.org> + <kvm@vger.kernel.org> + <linuxppc-dev@ozlabs.org> Alexander Graf <agraf@suse.de> Gleb Natapov <gleb@redhat.com> " Marcelo Tosatti <mtosatti@redhat.com>\0" @@ -91,4 +91,4 @@ "\n" -Scott -88d830f05f8192c8ee7dc65b93307c0fe97d0f1592ccd7f3a40353ebf774bc51 +c4b7e258c1df09356e98c1d745cdcc25c9da7282d7beded9431dad1db0876f41
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.