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

[Gleb Natapov]

On Sun, Mar 25, 2012 at 10:06:03AM -0500, Anthony Liguori wrote:
> On 03/25/2012 09:46 AM, Gleb Natapov wrote:
> >On Sun, Mar 25, 2012 at 08:09:37AM -0500, Anthony Liguori wrote:
> >>On 03/25/2012 05:19 AM, Gleb Natapov wrote:
> >>It's the Unix Philosophy:
> >>
> >>"Rule of Representation: Fold knowledge into data so program logic
> >>can be stupid and robust."
> >>
> >>If it can be reasonably represented as data, it should be.  If that
> >>data can be pushed to a flat text file, it should be.  If you can
> >>avoid making that special, you should.  This keeps your core logic
> >>simpler, empowers the user, and creates greater flexibility long
> >>term.
> >>
> >So you are making my point. You should be able to move data outside of
> >you code without it becoming user configurable file.
> 
> You're reading words that don't exist.
> 
I am pointing you to words that do not exist because you implying that
they somehow follow from the words that you wrote. They do not.

> >>Your whole argument seems to boil down to: I don't like this--but
> >>you aren't providing any concrete problems.  It doesn't make it
> >>harder to write a management tool, it's completely invisible to a
> >>user, and we have total control over the data files if they're
> >>stored in /usr/share.
> >>
> >I don't like what?
> 
> User configuration apparently.
I think that not everything should be user configuration, yes.

> 
> >Jugging by above two paragraph I am not so sure you
> >know. I am for moving cpu model definitions into separate file and putting
> >it into /usr/share. I am against QEMU not loading it.
> 
> Why are you trying to prevent a user from being able to control what QEMU 
> does?
> 
Because I want QEMU behave in deterministic manner. It means no devices
should disappear.

> >The reason I am
> >against it is because the file is not part of a machine configuration
> >and does not stands by it's own.
> 
> This is not a concrete argument.  It assumes that there's an agreed
> upon concept of "machine configuration" and "stands by it's own"
> which there obviously isn't.
> 
> What is the concrete technical or use-case argument here beyond that
> it doesn't match a concept that you have in your head of how things
> should be?
> 
If user tells me that he has -device virtio-net on the command line and
he uses qemu-1.0 I know exactly how this device works. Even if there is
-nodefconfig (whatever this thing does) on the command line. The same
should be true for -cpu nehalem.

> >It depends on combination of QEMU/KVM
> >and machine definition. You said in this thread that CPU types should be
> >treated like regular devices by machine type mechanism i.e machine types
> >should have list of properties for each cpu model which are different
> >from default.  I do agree with that but how is it going to work if you
> >do not event have standard model definitions that you can rely on.
> 
> Who is "you"?
"You" is you here:
http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg02077.html

>                QEMU will provide a list of models in /usr/share that
> are loaded by default.  If you actively disable it by using
> -nodefconfig, you're on your own.  I would personally never use
> -nodefconfig.  The only user of -nodefconfig is a management tool
> that is purposefully trying to make QEMU do the minimalistic amount
> of things possible.
> 
> I'm not sympathetic to arguments that user's are stupid and you have
> to keep them from doing things they shouldn't.  Defaults should Just
> Work and simple things should be simple to do.  But if a user
> expressly tells QEMU not to enable defaults, then they should know
> what they're doing.
> 
I personally do not like the idea of letting libvirt controlling such low
levels of QEMU as cpu models, but if you what to let them shoot
themselves in the foot we can compromise by allowing using cpu model
specification as a parameter to -cpu  (-cpu /watever/cpu-model-file). This
way libvirt will not be able to specify its own Nehalem cpu type by
mistake. But if/when we extend cpu model definition file format to
contain all information about all cpuid leafs I doubt they will want to
do that.

> >>So what's your concrete concern here?  Random comments about kvm
> >>tool or Gnome 3 are not concrete concerns.  What use-case do you
> >>think is impacted here and why (and please be specific)?
> >That are comment about QEMU usability. You do not consider that
> >important?
> >
> >>
> >>http://en.wikipedia.org/wiki/Unix_philosophy
> >>
> >Nothing there supports your design. Actually I think it contradicts at
> >least this:
> >  Rule of Clarity: Clarity is better than cleverness
> >You try to be clever, but in the end nobody expects CPU models to
> >disappear just because you asked QEMU to not create default machine.
> 
> It's not clever to me, it's obvious.
Not for me and reading your discussion with Avi and looking at the
subject line of the thread I tend to think you are the only one for
whom it is obvious.

> 
> >And you still didn't answer what is your view on current state of
> >affairs where cpu models in .c files are present while those in separate
> >file are diaper?
> 
> This is strictly a compatibility issue.  At this point in time, we
> could move the .c definitions to a configuration file as we've gone
> through enough releases with the default configuration file present.
> 
You do not need to move then into config file to make them disappear
with -nodefconfig. Would you except a patch?

> >So you view it as a bug and is going to make those in
> >.c files disappear to ?
> 
> Absolutely.
> 
At least you are consistent :)

--
                        Gleb.