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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list