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

[Anthony Liguori]

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