From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 04/19] qemu-kvm: x86: Drop MSR reset Date: Thu, 05 May 2011 10:27:46 +0200 Message-ID: <4DC25F82.2040501@siemens.com> References: <4DC25AF3.6050704@redhat.com> <4DC25BC5.9090801@siemens.com> <4DC25CDB.9060805@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm@vger.kernel.org" To: Avi Kivity Return-path: Received: from goliath.siemens.de ([192.35.17.28]:28094 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753073Ab1EEI1y (ORCPT ); Thu, 5 May 2011 04:27:54 -0400 In-Reply-To: <4DC25CDB.9060805@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-05-05 10:16, Avi Kivity wrote: > On 05/05/2011 11:11 AM, Jan Kiszka wrote: >> On 2011-05-05 10:08, Avi Kivity wrote: >>> On 05/04/2011 10:43 PM, Jan Kiszka wrote: >>>> From: Jan Kiszka >>>> >>>> Paravirtual MSRs are properly cleared on reset now, and blindly clearing >>>> the rest is questionable anyway (better address those one by one, >>>> re-initializing their backing CPU state fields). >>>> >>> >>> This can introduce a regression when new paravirtual MSRs are added. >> >> You mean MSRs already included or future ones? > > Future ones. > >>> So >>> we either need to port this, or query the reset state from the kernel >>> immediately after creating the vcpu and saving it. >> >> Can't completely follow what you mean. >> >> My general point remains: Every MSR requires individual care, not blind >> overwriting like qemu-kvm does. So the person contributing a new MSR, >> real or pv, has to tackle this aspect, and we need to review the code in >> this regard. > > It's a trick to avoid needing individual care. > > 1. Call KVM_CREATE_VCPU. This causes all MSRs to be initialized to > their power-on reset values. Almost all: Which ones are CPU specific like the APIC_BASE? > 2. Issue KVM_GET_MSR_LIST, and then KVM_GET_MSRS to read all MSRs. > Stash them all in safe places - the ones known to qemu but also the > unknown ones. Qemu may use its own values for the MSRs it knows about > (for example if different cpu models have different power-on values) > 3. On reset, issue KVM_SET_MSRS with the MSR values obtained in step 2. > > The result is forward and backwards compatibility without lockstepping > qemu and kvm. OK, sounds good. I will work out a patch for uq/master. Nevertheless, the qemu-kvm code is already unneeded today and can safely be removed IMHO. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux