qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 0/2] GET_EMULATED_CPUID support with "allow-emulat


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [RFC 0/2] GET_EMULATED_CPUID support with "allow-emulation" option
Date: Thu, 5 Jun 2014 14:17:15 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Jun 05, 2014 at 06:45:16PM +0200, Alexander Graf wrote:
> 
> On 05.06.14 18:44, Paolo Bonzini wrote:
> >Il 05/06/2014 18:40, Alexander Graf ha scritto:
> >>
> >>
> >>  kvm_set_cpuid(cpuid);
> >>
> >>but enabling all experimental features inside KVM just because we want
> >>one or two of them is very counter-intuitive. Imagine we'd introduce
> >>emulation support for AVX. Suddenly allow-emulation (which I'd need for
> >>Mac OS X 10.5) would enable AVX as well which I really don't want
> >>enabled.
> >
> >Only if you were using "-cpu somethingThatHasAVX", though, no?
> 
> Yes. The same argument goes the other way around. I want to use AVX
> emulation, do "allow-emulation" and suddenly I get MONITOR/MWAIT
> emulation.

This patch is just changing the set of _allowed_ bits, it is _not_
changing the actual semantics of a given "-cpu" option combination.
Unless you are not using the "enforce" flag, but you should be using it
if you care about not having CPUID data changing under your feet.

If you don't want MONITOR/MWAIT you shouldn't be using a CPU model
containing MONITOR/MWAIT in the first place. If you use "-cpu
somethingWithMONITOR", that means you are already asking QEMU for a CPU
with MONITOR. If you were not getting MONITOR before using
allow-emulation, that means you were not using the "enforce" flag, which
you should be using, already.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]