From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 04/19] qemu-kvm: x86: Drop MSR reset Date: Thu, 05 May 2011 11:33:33 +0300 Message-ID: <4DC260DD.5010807@redhat.com> References: <4DC25AF3.6050704@redhat.com> <4DC25BC5.9090801@siemens.com> <4DC25CDB.9060805@redhat.com> <4DC25F82.2040501@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm@vger.kernel.org" To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:59394 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751744Ab1EEIdj (ORCPT ); Thu, 5 May 2011 04:33:39 -0400 In-Reply-To: <4DC25F82.2040501@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/05/2011 11:27 AM, Jan Kiszka wrote: > > > > 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? Do you mean cpu specific as in smp or cpu specific as in cpu model? If the former, we simply do the reset operation per-cpu. It's the natural thing anyway. > > 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. Great, thanks. > Nevertheless, the qemu-kvm code is already unneeded today and can safely > be removed IMHO. I don't follow? Won't it cause a regression? Of course, if we get a patch soon no one will ever see the regression so we can apply the series. -- error compiling committee.c: too many arguments to function