[Qemu-devel] Re: [PATCH 2/2] introduce -cpu host target

[Avi Kivity]

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