From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] i386: wire up MSR_IA32_MISC_ENABLE Date: Tue, 04 Oct 2011 19:21:11 +0200 Message-ID: <4E8B4087.4060906@redhat.com> References: <1317738395-6488-1-git-send-email-avi@redhat.com> <4E8B2EB8.80408@web.de> <4E8B3D83.8050903@redhat.com> <4E8B3EDE.3060306@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53225 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755650Ab1JDRVP (ORCPT ); Tue, 4 Oct 2011 13:21:15 -0400 In-Reply-To: <4E8B3EDE.3060306@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 10/04/2011 07:14 PM, Jan Kiszka wrote: > > > >> > + > >> > +static const VMStateDescription vmstate_msr_ia32_misc_enable = { > >> > + .name = "cpu/msr_ia32_misc_enable", > >> > + .version_id = 1, > >> > + .minimum_version_id = 1, > >> > + .minimum_version_id_old = 1, > >> > + .fields = (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? Well let's fix subsections instead of disabling migration to older versions. > >> > >> 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 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? Practically all MSRs. i486 doesn't have any, IIRC, for example. (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) -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB8g9-0007YK-Bx for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:21:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RB8g7-0004zB-NL for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:21:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44239) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB8g7-0004z7-EV for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:21:15 -0400 Message-ID: <4E8B4087.4060906@redhat.com> Date: Tue, 04 Oct 2011 19:21:11 +0200 From: Avi Kivity 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> In-Reply-To: <4E8B3EDE.3060306@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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: Jan Kiszka Cc: Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org On 10/04/2011 07:14 PM, Jan Kiszka wrote: > > > >> > + > >> > +static const VMStateDescription vmstate_msr_ia32_misc_enable = { > >> > + .name = "cpu/msr_ia32_misc_enable", > >> > + .version_id = 1, > >> > + .minimum_version_id = 1, > >> > + .minimum_version_id_old = 1, > >> > + .fields = (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? Well let's fix subsections instead of disabling migration to older versions. > >> > >> 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 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? Practically all MSRs. i486 doesn't have any, IIRC, for example. (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) -- error compiling committee.c: too many arguments to function