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 13:22:32 +0300 Message-ID: <4DC27A68.3070409@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> <4DC265A5.90301@redhat.com> <4DC26EAA.7080803@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]:47811 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753533Ab1EEK2H (ORCPT ); Thu, 5 May 2011 06:28:07 -0400 In-Reply-To: <4DC26EAA.7080803@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/05/2011 12:32 PM, Jan Kiszka wrote: > >> > > >> > 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. IMO a few hundred bytes is worth the correctness here. > > > >> >> 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. The problem is with hardware MSRs (PV MSRs are protected by cpuid, and always disable themselves when zeroed). > 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. What I suggested wasn't zeroing them, but writing the value we read just after vcpu creation. We had a regression when we started supporting PAT. Zeroing it causes the cache to be disabled, making everything ridiculously slow. We now special case it; my proposed solution would have taken care of it. -- error compiling committee.c: too many arguments to function