qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models
Date: Tue, 23 Jun 2015 15:11:32 -0300
User-agent: Mutt/1.5.23 (2014-03-12)

On Tue, Jun 23, 2015 at 07:58:44PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 19:45 schrieb Eduardo Habkost:
> > On Tue, Jun 23, 2015 at 07:41:50PM +0200, Andreas Färber wrote:
> > [...]
> >> If that is the whole problem here, then why not just add a global flag
> >> to only enable explicitly requested KVM features? All other features
> >> should not depend on the host, and the whole discussion about -x.y seems
> >> like a distraction.
> > 
> > Now replace "KVM features" with "CPU fatures", because all CPU features
> > are KVM features, as all of them depend on KVM code enabling them on
> > GET_SUPPORTED_CPUID.
> > 
> > Thus, the global flag to only enable explicitly request KVM features on
> > CPUs is "-cpu custom", which doesn't enable any CPU feature at all.
> 
> If libvirt wants to use an empty CPU model, then why export our models
> to libvirt?

We wouldn't need it anymore. We would probably keep it just because old
libvirt versions (or maybe the non-x86 libvirt code) may use it, or
maybe libvirt will keep using the existing QEMU models for existing VMs
(because that would be simpler than converting existing "-cpu Foo" to
"-cpu custom -readconfig").

> 
> I don't mind there being an optional custom model, I mind our
> compat_props getting ignored that way, which are unrelated to adding new
> features, in fact they suppress just that for the -2.3 examples.

I am also not happy for having spent lots of time on compat_props for
CPUs when it is not going to be needed by libvirt anymore, but that's a
sunk cost.

-- 
Eduardo



reply via email to

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