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

[Anthony Liguori]

On 03/25/2012 10:45 AM, Avi Kivity wrote:
> On 03/25/2012 05:30 PM, Anthony Liguori wrote:
> > On 03/25/2012 10:18 AM, Avi Kivity wrote:
> > > On 03/25/2012 05:07 PM, Anthony Liguori wrote:
> > > > > As log as qemu -nodefconfig -cpu westmere -M pc1.1
> > > >
> > > >
> > > > -nodefconfig is going to eventually mean that -cpu westmere and -M
> > > > pc-1.1 will not work.
> > > >
> > > > This is where QEMU is going.  There is no reason that a normal user
> > > > should ever use -nodefconfig.
> > >
> > > I don't think anyone or anything can use it, since it's meaning is not
> > > well defined.  "not read any configuration files" where parts of qemu
> > > are continually moved out to configuration files means its a moving
> > > target.
> >
> > I think you assume that all QEMU users care about forward and
> > backwards compatibility on the command line about all else.
> >
> > That's really not true.  The libvirt folks have stated repeatedly that
> > command line backwards compatibility is not critical to them.  They
> > are happy to require that a new version of QEMU requires a new version
> > of libvirt.
>
> I don't think this came out of happiness, but despair.  Seriously,
> keeping compatibility is one of the things we work hardest to achieve,
> and we can't manage it for our command line?

I hate to burst your bubble, but we struggle and rarely maintain the level of 
compatibility you're seeking to have.

I agree with you that we need to do a better job maintaining compatibility which 
is why I'm trying to clearly separate the things that we will never break from 
the things that will change over time.

-nodefconfig is a moving target.  If you want stability, don't use it.  If you 
just want to prevent the user's /etc/qemu stuff from being loaded, use 
-no-user-config.

> > I'm not saying that backwards compat isn't important--it is.  But
> > there are users who are happy to live on the bleeding edge.
>
> That's fine, but I don't see how -nodefconfig helps them.  All it does
> is take away the building blocks (definitions) that they can use when
> setting up their configuration.

Yes, this is a feature.

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

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.

Regards,

Anthony Liguori