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

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.

Again, defining = #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(a)/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?

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.

> 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(a)/target-x86_64-cpus.cfg > # Load default machines > readconfig = @DATADIR(a)/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.

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

>>>> 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.

> >>> -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.