Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Anthony Liguori]

On 03/25/2012 09:46 AM, Avi Kivity wrote:
> On 03/25/2012 04:36 PM, Anthony Liguori wrote:
> > > Apart from the command line length, it confuses configuration with
> > > definition.
> >
> >
> > There is no distinction with what we have today.  Our configuration
> > file basically corresponds to command line options and as there is no
> > distinction in command line options, there's no distinction in the
> > configuration format.
>
> We don't have command line options for defining, only configuring.

That's an oversight.  There should be a -cpudef option.  It's a QemuOptsList.

> Again, defining = #define

I think -global fits your definition of #define...

> Configuring = modifying current instance
>
> > > target-x86_64-cpus.cfg does not configure qemu for anything, it's merely
> > > the equivalent of
> > >
> > >     #define westmere (x86_def_t) { ... }
> > >     #define nehalem (x86_def_t) { ... }
> > >     #define bulldozer (x86_def_t) { ... } // for PC
> > >
> > > so it should be read at each invocation.  On the other hand, pc.cfg and
> > > westmere.cfg (as used previously) are shorthand for
> > >
> > >      machine = (QEMUMachine) { ... };
> > >      cpu = (x86_def_t) { ... };
> > >
> > > so they should only be read if requested explicitly (or indirectly).
> >
> > This doesn't make a lot of sense to me.  Here's what I'm proposing:
> >
> > 1) QEMU would have a target-x86_64-cpu.cfg.in that is installed by
> > default in /etc/qemu.  It would contain:
> >
> > [system]
> > # Load default CPU definitions
> > readconfig = @DATADIR@/target-x86_64-cpus.cfg
> >
> > 2) target-x86_64-cpus.cfg would be installed to @DATADIR@ and would
> > contain:
> >
> > [cpudef]
> >    name = "Westmere"
> >    ...
> >
> > This has the following properties:
> >
> > A) QEMU has no builtin notion of CPU definitions.  It just has a "cpu
> > factory".  -cpudef will create a new class called Westmere that can
> > then be enumerated through qom-type-list and created via qom-create.
> >
> > B) A management tool has complete control over cpu definitions without
> > modifying the underlying filesystem.  -nodefconfig will prevent it
> > from loading and the management tool can explicitly load the QEMU
> > definition (via -readconfig, potentially using a /dev/fd/N path) or it
> > can define it's own cpu definitions.
>
> Why does -nodefconfig affect anything?

Because -nodefconfig means "don't load *any* default configuration files".

> The file defines westmere as an alias for a grab bag of options.
> Whether it's loaded or not is immaterial, unless someone uses one of the
> names within.

But you would agree, a management tool should be able to control whether class 
factories get loaded, right?  So what's the mechanism to do this?

> > C) This model maps to any other type of class factory.  Machines will
> > eventually be expressed as a class factory.  When we implement this,
> > we would change the default target-x86_64-cpu.cfg to:
> >
> > [system]
> > # Load default CPU definitions
> > readconfig = @DATADIR@/target-x86_64-cpus.cfg
> > # Load default machines
> > readconfig = @DATADIR@/target-x86_64-machines.cfg
> >
> > A machine definition would look like:
> >
> > [machinedef]
> >   name = pc-0.15
> >   virtio-blk.class_code = 32
> >   ...
> >
> > Loading a file based on -cpu doesn't generalize well unless we try to
> > load a definition for any possible QOM type to find the class factory
> > for it.  I don't think this is a good idea.
>
> Why not load all class factories?  Just don't instantiate any objects.

Unless we have two different config syntaxes, I think it will lead to a lot of 
confusion.  Having some parts of a config file be parsed and others not is 
fairly strange.

> Otherwise, the meaning of -nodefconfig changes as more stuff is moved
> out of .c and into .cfg.

What's the problem with this?

> > > > > The reasoning is, loading target-x86_64-cpus.cfg does not alter the
> > > > > current instance's configuration, so reading it doesn't violate
> > > > > -nodefconfig.
> > > >
> > > > I think we have a different view of what -nodefconfig does.
> > > >
> > > > We have a couple options today:
> > > >
> > > > -nodefconfig
> > > >
> > > > Don't read the default configuration files.  By default, we read
> > > > /etc/qemu/qemu.cfg and /etc/qemu/target-$(ARCH).cfg
> > >
> > > The latter seems meaningless to avoid reading.  It's just a set of
> > > #defines, what do you get by not reading it?
> >
> > In my target-$(ARCH).cfg, I have:
> >
> > [machine]
> > enable-kvm = "on"
> >
> > Which means I don't have to use -enable-kvm anymore.  But if you look
> > at a tool like libguestfs, start up time is the most important thing
> > so avoiding unnecessary I/O and processing is critical.
>
> So this is definitely configuration (applies to the current instance) as
> opposed to target-x86_64.cfg, which doesn't.

I'm not sure which part you're responding to..

> > > > -nodefaults
> > > >
> > > > Don't create default devices.
> > > >
> > > > -vga none
> > > >
> > > > Don't create the default VGA device (not covered by -nodefaults).
> > > >
> > > > With these two options, the semantics you get an absolutely
> > > > minimalistic instance of QEMU.  Tools like libguestfs really want to
> > > > create the simplest guest and do the least amount of processing so the
> > > > guest runs as fast as possible.
> > > >
> > > > It does suck a lot that this isn't a single option.  I would much
> > > > prefer -nodefaults to be implied by -nodefconfig.  Likewise, I would
> > > > prefer that -nodefaults implied -vga none.
> > >
> > > I don't have a qemu.cfg so can't comment on it, but in what way does
> > > reading target-x86_64.cfg affect the current instance (that is, why is
> > > -nodefconfig needed over -nodefaults -vga look-at-the-previous-option?)
> >
> > It depends on what the user configures it to do.
>
> How?
>
> As far as I can tell, the only difference is that -nodefconfig -cpu
> westmere will error out instead of working.  But if you don't supply
> -cpu westmere, the configuration is identical.

What configuration?

Let me ask, what do you think the semantics of -nodefconfig should be?  I'm not 
sure I understand what you're advocating for.

Regards,

Anthony Liguori