From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/2] introduce -cpu host target Date: Wed, 24 Jun 2009 14:26:06 +0300 Message-ID: <4A420D4E.4060005@redhat.com> References: <1245707277-769-1-git-send-email-andre.przywara@amd.com> <4A41F7EC.2000305@redhat.com> <4A420836.10302@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, kvm@vger.kernel.org To: Andre Przywara Return-path: Received: from mx2.redhat.com ([66.187.237.31]:48814 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751428AbZFXLZH (ORCPT ); Wed, 24 Jun 2009 07:25:07 -0400 In-Reply-To: <4A420836.10302@amd.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/24/2009 02:04 PM, Andre Przywara wrote: > Avi Kivity wrote: >> On 06/23/2009 12:47 AM, Andre Przywara wrote: >>> Should we ignore unhandled MSRs like QEMU or Xen do? >> >> Ignoring unhandled msrs is dangerous. If a write has some effect the >> guest depends on, and we're not emulating that effect, the guest will >> fail. Similarly if you don't know what a register mean, who knows >> what returning zero for a read will do. > I agree - from an academic POV. > But if the pragmatic approach simply enables many guests to run, then > it's at least worth considering it. > And with the current approach the guest fails, too (due to the > injected #GP). > If I only look at AMD's list of MSRs (not to speak of the internal > list ;-), there will be a lot of work to emulate them. Even worse, > most of them cannot be properly emulated (like disable Lock prefix). We don't need to emulate all values. We can allow default values or bits that don't matter for virtualization, and warn on bits that don't emulate properly. I'm not concerned about failure -- just silent failure. > > But nevertheless I would like to continue the "patch-on-demand" path > by catching those MSRs that in-the-wild OSes really touch and handle > them appropriately. Hopefully that will cover most of the MSRs. > Maybe we could consider an (module? QEMU cmdline?) option to ignore > unknown MSRs. Good idea. We can start with a module option, if it proves popular we can graduate it to a per-guest ioctl. -- error compiling committee.c: too many arguments to function