Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 01:09 PM, Avi Kivity wrote:
>>>> Suppose we define the southbridge via a configuration
file. Does that
>>>> mean we don't load it any more?
>>>
>>> Yes. If I want the leanest and meanest version of QEMU that will
>>> start in the smallest number of milliseconds, then being able to tell
>>> QEMU not to load configuration files and create a very specific
>>> machine is a Good Thing. Why exclude users from being able to do this?
>>
>> So is this the point? Reducing startup time?
>
> Yes, that's one reason. But maybe a user wants to have a whole
> different set of machine types and doesn't care to have the ones we
> provide. Why prevent a user from doing this?
How are we preventing a user from doing it? In what way is -nodefconfig
helping it?
Let me explain it in a different way, perhaps.
We launch smbd in QEMU in order to do file sharing over slirp. One of the
historic problems we've had is that we don't assume root privileges, yet want to
be able to run smbd without using any of the system configuration files.
You can do this by specify -s with the config file, and then in the config file
you can overload the various default paths (like private dir, lock dir, etc.).
In some cases, earlier versions of smbd didn't allow you to change private dir.
You should be able to tell a well behaved tool not to read any
configuration/data files and explicitly tell it where/how to read them. We
cannot exhaustively anticipate every future use case of QEMU.
But beyond the justification for -nodefconfig, the fact is that it exists today,
and has a specific semantic. If we want to have a different semantic, we should
introduce a new option (-no-user-config).
Regards,
Anthony Liguori
> Maybe they have a management tool that attempts to totally hide
QEMU
> from the end user and exposes a different set of machine types. It's
> certainly more convenient for something like the Android emulator to
> only have to deal with QEMU knowing about the 4 types of machines that
> it specifically supports.
If it supports four types, it should always pass one of them to qemu.
The only thing -nodefconfig adds is breakage when qemu moves something
that one of those four machines relies on to a config file.