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 10:11:49 +0200 Message-ID: <4DC25BC5.9090801@siemens.com> References: <4DC25AF3.6050704@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 thoth.sbs.de ([192.35.17.2]:21423 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751051Ab1EEIL4 (ORCPT ); Thu, 5 May 2011 04:11:56 -0400 In-Reply-To: <4DC25AF3.6050704@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-05-05 10:08, Avi Kivity wrote: > On 05/04/2011 10:43 PM, Jan Kiszka wrote: >> From: Jan Kiszka >> >> Paravirtual MSRs are properly cleared on reset now, and blindly clearing >> the rest is questionable anyway (better address those one by one, >> re-initializing their backing CPU state fields). >> > > This can introduce a regression when new paravirtual MSRs are added. You mean MSRs already included or future ones? > So > we either need to port this, or query the reset state from the kernel > immediately after creating the vcpu and saving it. Can't completely follow what you mean. My general point remains: Every MSR requires individual care, not blind overwriting like qemu-kvm does. So the person contributing a new MSR, real or pv, has to tackle this aspect, and we need to review the code in this regard. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux