[libvirt] [Qemu-devel] [QEMU PATCH 3/3] x86: pc: versioned CPU model names & compatibility aliases

Eduardo Habkost ehabkost at redhat.com
Tue Jul 31 13:44:23 UTC 2012


On Tue, Jul 31, 2012 at 03:22:59PM +0200, Igor Mammedov wrote:
> On Thu, Jul 26, 2012 at 10:48:45AM -0400, Eduardo Habkost wrote:
> ... 
> > 
> > [1] There are multiple changes I want to make the cpudef config format:
> > 
> > - Make it based on boolean per-feature flags, not low-level
> >   feature_<register> bits
> I'm trying to convert features to properties before looking at global props.
> current state is at https://github.com/imammedo/qemu/tree/x86-cpu-properties.WIP
> Does it represent something you have in mind?

Yes, it's like what I have in mind.

But note that cpudefs are not objects, yet. We have lots of people
focusing on the CPU objects themselves, but the cpudefs read from the
config are still plain old structs, with no properties, and there's no
clear plan on how to model them in the code.

Even if we convert the cpudefs to become classes, we still don't have a
simple way to make the cpudef read from the config file set CPU
properties only for specific classes.

Some of the approaches I see:
- Make classes have properties, too;
- Make cpudefs be full-featured objects, that are used as argument when
  creating CPU objects;
- Do it manually: have a feature bitmap (or other data structure) for
  each CPU class, translate the cpudef config options to that bitmap
  manually, and translate it to CPU features manually when creating the
  CPU object;
- Translate all the cpudef sections to global properties, that would
  in turn set CPU properties once the CPU objects are created.

The last option seems to work (once we make the CPU objects really able
to use global properties). But I have the feeling that setting lots of
global properties by default is an abuse of the global property system.

-- 
Eduardo




More information about the libvir-list mailing list