From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] i386: wire up MSR_IA32_MISC_ENABLE Date: Tue, 04 Oct 2011 19:14:06 +0200 Message-ID: <4E8B3EDE.3060306@web.de> References: <1317738395-6488-1-git-send-email-avi@redhat.com> <4E8B2EB8.80408@web.de> <4E8B3D83.8050903@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD3C9E0527E9A910017D7439D" Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:59208 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932204Ab1JDROb (ORCPT ); Tue, 4 Oct 2011 13:14:31 -0400 In-Reply-To: <4E8B3D83.8050903@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD3C9E0527E9A910017D7439D Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2011-10-04 19:08, Avi Kivity wrote: > On 10/04/2011 06:05 PM, Jan Kiszka wrote: >> On 2011-10-04 16:26, Avi Kivity wrote: >> > It's needed for its default value - bit 0 specifies that "rep movs"= is >> > good enough for memcpy, and Linux may use a slower memcpu if it is >> not set, >> > depending on cpu family/model. >> > >> > Signed-off-by: Avi Kivity >> > --- >> > target-i386/cpu.h | 5 +++++ >> > target-i386/helper.c | 1 + >> > target-i386/kvm.c | 15 +++++++++++++++ >> > target-i386/machine.c | 21 +++++++++++++++++++++ >> > target-i386/op_helper.c | 6 ++++++ >> > 5 files changed, 48 insertions(+), 0 deletions(-) >> > >> > diff --git a/target-i386/cpu.h b/target-i386/cpu.h >> > index ae36489..5416809 100644 >> > --- a/target-i386/cpu.h >> > +++ b/target-i386/cpu.h >> > @@ -299,6 +299,10 @@ >> > >> > #define MSR_IA32_PERF_STATUS 0x198 >> > >> > +#define MSR_IA32_MISC_ENABLE 0x1a0 >> >> I smell tabs... >=20 > Oops. Cut'n'paste flew underneath the emacs radar. >=20 >> > + >> > +static const VMStateDescription vmstate_msr_ia32_misc_enable =3D {= >> > + .name =3D "cpu/msr_ia32_misc_enable", >> > + .version_id =3D 1, >> > + .minimum_version_id =3D 1, >> > + .minimum_version_id_old =3D 1, >> > + .fields =3D (VMStateField []) { >> > + VMSTATE_UINT64(msr_ia32_misc_enable, CPUState), >> > + VMSTATE_END_OF_LIST() >> > + } >> > +}; >> > + >> >> We are about to bump the CPU_SAVE_VERSION for the sake of APIC deadlin= e >> timer, so you can jump on that train and avoid this subsection. >=20 > Must we do that? Considering that no guest will use the deadline timer= , > it seems to be an excellent candidates for subsections. I don't know, it was sent out for pull like that. And I thought subsections are still broken, aren't they? >=20 >> > diff --git a/target-i386/op_helper.c b/target-i386/op_helper.c >> > index 3bb5a91..c89e4a4 100644 >> > --- a/target-i386/op_helper.c >> > +++ b/target-i386/op_helper.c >> > @@ -3280,6 +3280,9 @@ void helper_wrmsr(void) >> > case MSR_TSC_AUX: >> > env->tsc_aux =3D val; >> > break; >> > + case MSR_IA32_MISC_ENABLE: >> > + env->msr_ia32_misc_enable =3D val; >> > + break; >> >> This MSR is Intel-specific, isn't it? Then I guess it should be limite= d >> to Intel CPU types. >=20 > It's an "architectural MSR" that is only available on some Intel > models. Either we do a full cpuid qualification of accessible MSRs (an= d > bits within MSRs), or not. Qualifying just by vendor ID is pointless. Given that, when in conflict, we rather model after AMD than Intel for TCG, I would hesitate to expose this by default. Or are there precedences already? Jan --------------enigD3C9E0527E9A910017D7439D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6LPt4ACgkQitSsb3rl5xRe9ACg7RInPuaD8nJGM+aSLSNiSv26 jcoAoJJyDGsNWPCs3VngK8Bm+7oGBDMX =R8jc -----END PGP SIGNATURE----- --------------enigD3C9E0527E9A910017D7439D-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB8Zd-0004gB-Az for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:14:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RB8Zc-0003x6-4T for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:14:33 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:59193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB8Zb-0003x0-Ml for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:14:32 -0400 Message-ID: <4E8B3EDE.3060306@web.de> Date: Tue, 04 Oct 2011 19:14:06 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1317738395-6488-1-git-send-email-avi@redhat.com> <4E8B2EB8.80408@web.de> <4E8B3D83.8050903@redhat.com> In-Reply-To: <4E8B3D83.8050903@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD3C9E0527E9A910017D7439D" Sender: jan.kiszka@web.de Subject: Re: [Qemu-devel] [PATCH] i386: wire up MSR_IA32_MISC_ENABLE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD3C9E0527E9A910017D7439D Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2011-10-04 19:08, Avi Kivity wrote: > On 10/04/2011 06:05 PM, Jan Kiszka wrote: >> On 2011-10-04 16:26, Avi Kivity wrote: >> > It's needed for its default value - bit 0 specifies that "rep movs"= is >> > good enough for memcpy, and Linux may use a slower memcpu if it is >> not set, >> > depending on cpu family/model. >> > >> > Signed-off-by: Avi Kivity >> > --- >> > target-i386/cpu.h | 5 +++++ >> > target-i386/helper.c | 1 + >> > target-i386/kvm.c | 15 +++++++++++++++ >> > target-i386/machine.c | 21 +++++++++++++++++++++ >> > target-i386/op_helper.c | 6 ++++++ >> > 5 files changed, 48 insertions(+), 0 deletions(-) >> > >> > diff --git a/target-i386/cpu.h b/target-i386/cpu.h >> > index ae36489..5416809 100644 >> > --- a/target-i386/cpu.h >> > +++ b/target-i386/cpu.h >> > @@ -299,6 +299,10 @@ >> > >> > #define MSR_IA32_PERF_STATUS 0x198 >> > >> > +#define MSR_IA32_MISC_ENABLE 0x1a0 >> >> I smell tabs... >=20 > Oops. Cut'n'paste flew underneath the emacs radar. >=20 >> > + >> > +static const VMStateDescription vmstate_msr_ia32_misc_enable =3D {= >> > + .name =3D "cpu/msr_ia32_misc_enable", >> > + .version_id =3D 1, >> > + .minimum_version_id =3D 1, >> > + .minimum_version_id_old =3D 1, >> > + .fields =3D (VMStateField []) { >> > + VMSTATE_UINT64(msr_ia32_misc_enable, CPUState), >> > + VMSTATE_END_OF_LIST() >> > + } >> > +}; >> > + >> >> We are about to bump the CPU_SAVE_VERSION for the sake of APIC deadlin= e >> timer, so you can jump on that train and avoid this subsection. >=20 > Must we do that? Considering that no guest will use the deadline timer= , > it seems to be an excellent candidates for subsections. I don't know, it was sent out for pull like that. And I thought subsections are still broken, aren't they? >=20 >> > diff --git a/target-i386/op_helper.c b/target-i386/op_helper.c >> > index 3bb5a91..c89e4a4 100644 >> > --- a/target-i386/op_helper.c >> > +++ b/target-i386/op_helper.c >> > @@ -3280,6 +3280,9 @@ void helper_wrmsr(void) >> > case MSR_TSC_AUX: >> > env->tsc_aux =3D val; >> > break; >> > + case MSR_IA32_MISC_ENABLE: >> > + env->msr_ia32_misc_enable =3D val; >> > + break; >> >> This MSR is Intel-specific, isn't it? Then I guess it should be limite= d >> to Intel CPU types. >=20 > It's an "architectural MSR" that is only available on some Intel > models. Either we do a full cpuid qualification of accessible MSRs (an= d > bits within MSRs), or not. Qualifying just by vendor ID is pointless. Given that, when in conflict, we rather model after AMD than Intel for TCG, I would hesitate to expose this by default. Or are there precedences already? Jan --------------enigD3C9E0527E9A910017D7439D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6LPt4ACgkQitSsb3rl5xRe9ACg7RInPuaD8nJGM+aSLSNiSv26 jcoAoJJyDGsNWPCs3VngK8Bm+7oGBDMX =R8jc -----END PGP SIGNATURE----- --------------enigD3C9E0527E9A910017D7439D--