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:53:57 +0300 Message-ID: <4DC265A5.90301@redhat.com> References: <4DC25AF3.6050704@redhat.com> <4DC25BC5.9090801@siemens.com> <4DC25CDB.9060805@redhat.com> <4DC25F82.2040501@siemens.com> <4DC260DD.5010807@redhat.com> <4DC26388.4090207@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]:25157 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753155Ab1EEIyf (ORCPT ); Thu, 5 May 2011 04:54:35 -0400 In-Reply-To: <4DC26388.4090207@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/05/2011 11:44 AM, Jan Kiszka wrote: > On 2011-05-05 10:33, Avi Kivity wrote: > > 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? > > Yep. Doh. > > > > If the former, we simply do the reset operation per-cpu. It's the > > natural thing anyway. > > Quite wasteful /wrt to memory given that the majority will be identical. We're talking a few hundred bytes per cpu. If you want to save memory, look at the PhysPageDesc array, it takes up 0.4% of guest memory, so 4MB for a 1GB guest. > >> 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? > > Not at all. We use the "individual care" pattern upstream now, > specifically for those MSRs (kvmclock) for which the qemu-kvm code was > introduced. I mean a future regression with current+patch qemu and a new kernel. > > > > Of course, if we get a patch soon no one will ever see the regression so > > we can apply the series. > > I will still require the usual testing and merging round via upstream > and back. Not sure when I'll be able to work on it, probably not the > next days. If you can do it within a couple of weeks or so that should be fine. -- error compiling committee.c: too many arguments to function