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 14:57:46 +0300 Message-ID: <4DC290BA.70604@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> <4DC27A68.3070409@redhat.com> <4DC27DBB.5020500@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]:41934 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751156Ab1EEL5x (ORCPT ); Thu, 5 May 2011 07:57:53 -0400 In-Reply-To: <4DC27DBB.5020500@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/05/2011 01:36 PM, Jan Kiszka wrote: > > > > The problem is with hardware MSRs (PV MSRs are protected by cpuid, and > > always disable themselves when zeroed). > > Well, this doesn't change the problem of the existing code. Right. > > > > 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. > > I'm talking about the current code, not the proper way to do it in the > future. PAT demonstrates why regressions can happen as long as we zero > and it's better to stop this now even without the new code in place. I'm not sure, but if we do adopt the new reset mechanism, it doesn't matter. -- error compiling committee.c: too many arguments to function