diff for duplicates of <1372876276.8183.136@snotra> diff --git a/a/1.txt b/N1/1.txt index 7cf5e0d..7170b9d 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -20,44 +20,44 @@ On 07/03/2013 07:11:52 AM, Caraman Mihai Claudiu-B02008 wrote: > > > index 01eb635..019496d 100644 > > > --- a/arch/powerpc/kvm/booke.c > > > +++ b/arch/powerpc/kvm/booke.c -> > > @@ -1570,6 +1570,22 @@ int kvm_vcpu_ioctl_get_one_reg(struct +> > > @@ -1570,6 +1570,22 @@ int kvm_vcpu_ioctl_get_one_reg(struct =20 > kvm_vcpu > > > *vcpu, struct kvm_one_reg *reg) > > > case KVM_REG_PPC_DEBUG_INST: -> > > val = get_reg_val(reg->id, KVMPPC_INST_EHPRIV); +> > > val =3D get_reg_val(reg->id, KVMPPC_INST_EHPRIV); > > > break; > > > +#ifdef CONFIG_ALTIVEC > > > + case KVM_REG_PPC_VR0 ... KVM_REG_PPC_VR31: > > > + if (!cpu_has_feature(CPU_FTR_ALTIVEC)) { -> > > + r = -ENXIO; +> > > + r =3D -ENXIO; > > > + break; > > > + } -> > > + val.vval = vcpu->arch.vr[reg->id - KVM_REG_PPC_VR0]; +> > > + val.vval =3D vcpu->arch.vr[reg->id - KVM_REG_PPC_VR0]; > > > + break; > > > + case KVM_REG_PPC_VSCR: > > > + if (!cpu_has_feature(CPU_FTR_ALTIVEC)) { -> > > + r = -ENXIO; +> > > + r =3D -ENXIO; > > > + break; > > > + } -> > > + val = get_reg_val(reg->id, vcpu->arch.vscr.u[3]); +> > > + val =3D get_reg_val(reg->id, vcpu->arch.vscr.u[3]); > > > + break; > > > > Why u[3]? -> -> AltiVec PEM manual says: "The VSCR has two defined bits, the AltiVec +>=20 +> AltiVec PEM manual says: "The VSCR has two defined bits, the AltiVec =20 > non-Java -> mode (NJ) bit (VSCR[15]) and the AltiVec saturation (SAT) bit +> mode (NJ) bit (VSCR[15]) and the AltiVec saturation (SAT) bit =20 > (VSCR[31]); > the remaining bits are reserved." -> -> I think this is the reason Paul M. exposed KVM_REG_PPC_VSCR width as +>=20 +> I think this is the reason Paul M. exposed KVM_REG_PPC_VSCR width as =20 > 32-bit. -Ugh. It's documented as a 32-bit register in the ISA, but it can only -be accessed via a vector register (seems like an odd design choice, but -whatever). And the kernel chose to represent it as a 128-bit vector, -while KVM chose to represent it as the register (not the access -thereto) is architected. It would have been nice to be consistent... +Ugh. It's documented as a 32-bit register in the ISA, but it can only =20 +be accessed via a vector register (seems like an odd design choice, but =20 +whatever). And the kernel chose to represent it as a 128-bit vector, =20 +while KVM chose to represent it as the register (not the access =20 +thereto) is architected. It would have been nice to be consistent... =20 At least put in a comment explaining this. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index 1cee6f9..e3c8703 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,12 +1,12 @@ "ref\0300B73AA675FCE4A93EB4FC1D42459FF0A2A3592@039-SN2MPN1-013.039d.mgd.msft.net\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support\0" - "Date\0Wed, 03 Jul 2013 18:31:16 +0000\0" + "Date\0Wed, 3 Jul 2013 13:31:16 -0500\0" "To\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>\0" "Cc\0Wood Scott-B07421 <B07421@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 07:11:52 AM, Caraman Mihai Claudiu-B02008 wrote:\n" @@ -31,46 +31,46 @@ "> > > index 01eb635..019496d 100644\n" "> > > --- a/arch/powerpc/kvm/booke.c\n" "> > > +++ b/arch/powerpc/kvm/booke.c\n" - "> > > @@ -1570,6 +1570,22 @@ int kvm_vcpu_ioctl_get_one_reg(struct \n" + "> > > @@ -1570,6 +1570,22 @@ int kvm_vcpu_ioctl_get_one_reg(struct =20\n" "> kvm_vcpu\n" "> > > *vcpu, struct kvm_one_reg *reg)\n" "> > > \tcase KVM_REG_PPC_DEBUG_INST:\n" - "> > > \t\tval = get_reg_val(reg->id, KVMPPC_INST_EHPRIV);\n" + "> > > \t\tval =3D get_reg_val(reg->id, KVMPPC_INST_EHPRIV);\n" "> > > \t\tbreak;\n" "> > > +#ifdef CONFIG_ALTIVEC\n" "> > > +\tcase KVM_REG_PPC_VR0 ... KVM_REG_PPC_VR31:\n" "> > > +\t\tif (!cpu_has_feature(CPU_FTR_ALTIVEC)) {\n" - "> > > +\t\t\tr = -ENXIO;\n" + "> > > +\t\t\tr =3D -ENXIO;\n" "> > > +\t\t\tbreak;\n" "> > > +\t\t}\n" - "> > > +\t\tval.vval = vcpu->arch.vr[reg->id - KVM_REG_PPC_VR0];\n" + "> > > +\t\tval.vval =3D vcpu->arch.vr[reg->id - KVM_REG_PPC_VR0];\n" "> > > +\t\tbreak;\n" "> > > +\tcase KVM_REG_PPC_VSCR:\n" "> > > +\t\tif (!cpu_has_feature(CPU_FTR_ALTIVEC)) {\n" - "> > > +\t\t\tr = -ENXIO;\n" + "> > > +\t\t\tr =3D -ENXIO;\n" "> > > +\t\t\tbreak;\n" "> > > +\t\t}\n" - "> > > +\t\tval = get_reg_val(reg->id, vcpu->arch.vscr.u[3]);\n" + "> > > +\t\tval =3D get_reg_val(reg->id, vcpu->arch.vscr.u[3]);\n" "> > > +\t\tbreak;\n" "> >\n" "> > Why u[3]?\n" - "> \n" - "> AltiVec PEM manual says: \"The VSCR has two defined bits, the AltiVec \n" + ">=20\n" + "> AltiVec PEM manual says: \"The VSCR has two defined bits, the AltiVec =20\n" "> non-Java\n" - "> mode (NJ) bit (VSCR[15]) and the AltiVec saturation (SAT) bit \n" + "> mode (NJ) bit (VSCR[15]) and the AltiVec saturation (SAT) bit =20\n" "> (VSCR[31]);\n" "> the remaining bits are reserved.\"\n" - "> \n" - "> I think this is the reason Paul M. exposed KVM_REG_PPC_VSCR width as \n" + ">=20\n" + "> I think this is the reason Paul M. exposed KVM_REG_PPC_VSCR width as =20\n" "> 32-bit.\n" "\n" - "Ugh. It's documented as a 32-bit register in the ISA, but it can only \n" - "be accessed via a vector register (seems like an odd design choice, but \n" - "whatever). And the kernel chose to represent it as a 128-bit vector, \n" - "while KVM chose to represent it as the register (not the access \n" - "thereto) is architected. It would have been nice to be consistent... \n" + "Ugh. It's documented as a 32-bit register in the ISA, but it can only =20\n" + "be accessed via a vector register (seems like an odd design choice, but =20\n" + "whatever). And the kernel chose to represent it as a 128-bit vector, =20\n" + "while KVM chose to represent it as the register (not the access =20\n" + "thereto) is architected. It would have been nice to be consistent... =20\n" "At least put in a comment explaining this.\n" "\n" - -Scott + -Scott= -602afd4f4dc64eebcf556ce358a067683eb8a3f95363b8536a37a7f8aa8cc23b +6c30b59adf4d68a57f41adc13dbe132c9a94f238b61abeceae03b20fb82e9b07
diff --git a/a/content_digest b/N2/content_digest index 1cee6f9..6c58780 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,7 +1,7 @@ "ref\0300B73AA675FCE4A93EB4FC1D42459FF0A2A3592@039-SN2MPN1-013.039d.mgd.msft.net\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support\0" - "Date\0Wed, 03 Jul 2013 18:31:16 +0000\0" + "Date\0Wed, 3 Jul 2013 13:31:16 -0500\0" "To\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>\0" "Cc\0Wood Scott-B07421 <B07421@freescale.com>" kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org> @@ -73,4 +73,4 @@ "\n" -Scott -602afd4f4dc64eebcf556ce358a067683eb8a3f95363b8536a37a7f8aa8cc23b +2f7a4bfdf5b51326ba3a899a07ff2847b8319ebffdb6d4d418db34dc878a03f9
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.