[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130926185524.GA10123@pd.tnic>
Date: Thu, 26 Sep 2013 20:55:24 +0200
From: Borislav Petkov <bp@...en8.de>
To: Eduardo Habkost <ehabkost@...hat.com>
Cc: Gleb Natapov <gleb@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...e.de>, "H. Peter Anvin" <hpa@...or.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Andre Przywara <andre@...rep.de>,
Joerg Roedel <joro@...tes.org>, X86 ML <x86@...nel.org>,
KVM <kvm@...r.kernel.org>, qemu-devel@...gnu.org,
libvir-list@...hat.com, Jiri Denemark <jdenemar@...hat.com>
Subject: Re: [PATCH 1/6] kvm: Add KVM_GET_EMULATED_CPUID
On Thu, Sep 26, 2013 at 11:19:15AM -0300, Eduardo Habkost wrote:
> Then we may have a problem: some CPU models already have "movbe"
> included (e.g. Haswell), and patch 6/6 will make "-cpu Haswell" get
> movbe enabled even if it is being emulated.
Huh? HSW has MOVBE so we won't #UD on it and MOVBE will get executed in
hardware when executing the guest. IOW, we'll never get to the emulation
path of piggybacking on the #UD.
> So if we really want to avoid enabling emulated features by mistake,
> we may need a new CPU flag in addition to "enforce" to tell QEMU that
> it is OK to enable emulated features (maybe "-cpu ...,emulate"?).
EMULATED_CPUID are off by default and only if you request them
specifically, they get enabled. If you start with "-cpu Haswell", MOVBE
will be already set in the host CPUID.
Or am I missing something?
> But my question still stands: suppose we had x2apic emulation
> implemented but for some reason it was painfully slow, we wouldn't
> want to enable it by mistake. In this case, it would end up on
> EMULATED_CPUID and not on SUPPORTED_CPUID, right?
IMHO we want to enable emulation only when explicitly requested...
regardless of the emulation performance.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists