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:24:58 +0200 Message-ID: <4E8B416A.2090401@web.de> References: <1317738395-6488-1-git-send-email-avi@redhat.com> <4E8B2EB8.80408@web.de> <4E8B3D83.8050903@redhat.com> <4E8B3EDE.3060306@web.de> <4E8B4087.4060906@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2618DAC0F9423F10C55C55AB" Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:60126 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932809Ab1JDRZA (ORCPT ); Tue, 4 Oct 2011 13:25:00 -0400 In-Reply-To: <4E8B4087.4060906@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2618DAC0F9423F10C55C55AB Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2011-10-04 19:21, Avi Kivity wrote: > On 10/04/2011 07:14 PM, Jan Kiszka wrote: >> > >> >> > + >> >> > +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 >> deadline >> >> timer, so you can jump on that train and avoid this subsection. >> > >> > 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 > Well let's fix subsections instead of disabling migration to older > versions. >=20 >> >> >> >> This MSR is Intel-specific, isn't it? Then I guess it should be >> limited >> >> to Intel CPU types. >> > >> > It's an "architectural MSR" that is only available on some Intel >> > models. Either we do a full cpuid qualification of accessible MSRs= >> (and >> > bits within MSRs), or not. Qualifying just by vendor ID is pointle= ss. >> >> 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? >=20 > Practically all MSRs. i486 doesn't have any, IIRC, for example. Pre-Pentiums don't have instructions to access them as well, so that doesn't cause any harm. >=20 > (and given this MSR has no effect, the only difference it makes to > guests is the #GP we take or not; still it may be worthwhile to > construct some table-driven thing to allow or reject MSR accesses, both= > for kvm and qemu) Right. If this MSR is not the first bogus one on AMD, we can do this later. If it is, it should be done first. Jan --------------enig2618DAC0F9423F10C55C55AB 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/ iEYEARECAAYFAk6LQWoACgkQitSsb3rl5xQr4QCfYGqBN2tYcDbiE5pa+Q6yjI4m B4wAoMyAPlEf+oLLFmgk2xRxdEwDHwMv =UH1G -----END PGP SIGNATURE----- --------------enig2618DAC0F9423F10C55C55AB-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB8jp-0001wu-9o for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:25:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RB8jk-0005T5-Qm for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:25:05 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:60118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB8jk-0005T1-E4 for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:25:00 -0400 Message-ID: <4E8B416A.2090401@web.de> Date: Tue, 04 Oct 2011 19:24:58 +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> <4E8B3EDE.3060306@web.de> <4E8B4087.4060906@redhat.com> In-Reply-To: <4E8B4087.4060906@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2618DAC0F9423F10C55C55AB" 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) --------------enig2618DAC0F9423F10C55C55AB Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2011-10-04 19:21, Avi Kivity wrote: > On 10/04/2011 07:14 PM, Jan Kiszka wrote: >> > >> >> > + >> >> > +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 >> deadline >> >> timer, so you can jump on that train and avoid this subsection. >> > >> > 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 > Well let's fix subsections instead of disabling migration to older > versions. >=20 >> >> >> >> This MSR is Intel-specific, isn't it? Then I guess it should be >> limited >> >> to Intel CPU types. >> > >> > It's an "architectural MSR" that is only available on some Intel >> > models. Either we do a full cpuid qualification of accessible MSRs= >> (and >> > bits within MSRs), or not. Qualifying just by vendor ID is pointle= ss. >> >> 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? >=20 > Practically all MSRs. i486 doesn't have any, IIRC, for example. Pre-Pentiums don't have instructions to access them as well, so that doesn't cause any harm. >=20 > (and given this MSR has no effect, the only difference it makes to > guests is the #GP we take or not; still it may be worthwhile to > construct some table-driven thing to allow or reject MSR accesses, both= > for kvm and qemu) Right. If this MSR is not the first bogus one on AMD, we can do this later. If it is, it should be done first. Jan --------------enig2618DAC0F9423F10C55C55AB 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/ iEYEARECAAYFAk6LQWoACgkQitSsb3rl5xQr4QCfYGqBN2tYcDbiE5pa+Q6yjI4m B4wAoMyAPlEf+oLLFmgk2xRxdEwDHwMv =UH1G -----END PGP SIGNATURE----- --------------enig2618DAC0F9423F10C55C55AB--