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 11:32:26 +0200 Message-ID: <4DC26EAA.7080803@siemens.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> <4DC265A5.90301@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 fmmailgate01.web.de ([217.72.192.221]:56900 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751744Ab1EEJca (ORCPT ); Thu, 5 May 2011 05:32:30 -0400 In-Reply-To: <4DC265A5.90301@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-05-05 10:53, Avi Kivity wrote: > 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. I know (that's fixable, BTW). But that should not excuse needless memory wasting elsewhere. > >> >> 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. For sane scenarios, such a combination should never expose new (ie. unknown from qemu's POV) MSRs to the guest. Thus not clearing them cannot cause any harm. BTW, you also do not know if 0 will be the right reset value for these to-be-invented MSRs. That could cause regression as well. > >> > >> > 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. > We'll see, but I still do not share your concern regarding future regressions when removing the fragile reset code. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux