Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models

[Eduardo Habkost]

On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 17:58 schrieb Eduardo Habkost:
> > On Tue, Jun 23, 2015 at 05:32:42PM +0200, Michael S. Tsirkin wrote:
> >> On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
> >>> On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote:
> >>>> Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
> >>>>>> To help libvirt in the transition, a x86-cpu-model-dump script is 
> >>>>>> provided,
> >>>>>> that will generate a config file that can be loaded using -readconfig, 
> >>>>>> based on
> >>>>>> the -cpu and -machine options provided in the command-line.
> >>>>>
> >>>>> Thanks Eduardo, I never was a big fan of moving (or copying) all the CPU
> >>>>> configuration data to libvirt, but now I think it actually makes sense.
> >>>>> We already have a partial copy of CPU model definitions in libvirt
> >>>>> anyway, but as QEMU changes some CPU models in some machine types (and
> >>>>> libvirt does not do that) we have no real control over the guest CPU
> >>>>> configuration. While what we really want is full control to enforce
> >>>>> stable guest ABI.
> >>>>
> >>>> That sounds like FUD to me. Any concrete data points where QEMU does not
> >>>> have a stable ABI for x86 CPUs? That's what we have the pc*-x.y machines
> >>>> for.
> >>>
> >>> What Jiri is saying that the CPUs change depending on -mmachine, not
> >>> that the ABI is broken by a given machine.
> >>>
> >>> The problem here is that libvirt needs to provide CPU models whose
> >>> runnability does not depend on the machine-type. If users have a VM that
> >>> is running in a host and the VM machine-type changes,
> >>
> >> How does it change, and why?
> > 
> > Sometimes we add features to a CPU model because they were not emulated by 
> > KVM
> > and now they are. Sometimes we remove or add features or change other fields
> > because we are fixing previous mistakes. Recently we we were going to remove
> > features from models because of an Intel CPU errata, but then decided to 
> > create
> > a new CPU model name instead.
> > 
> > See some examples at the end of this message.
> > 
> >>
> >>> the VM should be
> >>> still runnable in that host. QEMU doesn't provide that, our CPU models
> >>> may change when we introduce new machine-types, so we are giving them a
> >>> mechanism that allows libvirt to implement the policy they need.
> >>
> >> I don't mind wrt CPU specifically, but we absolutely do change guest ABI
> >> in many ways when we change machine types.
> > 
> > All the other ABI changes we introduce in QEMU don't affect runnability of 
> > the
> > VM in a given host, that's the problem we are trying to address here. ABI
> > changes are expected when changing to a new machine, runnability changes
> > aren't.
> > 
> > 
> > Examples of commits changing CPU models:
> [snip]
> 
> I've always advocated remaining backwards-compatible and only making CPU
> model changes for new machines. You among others felt that was not
> always necessary, and now you're using the lack thereof as an argument
> to stop using QEMU's CPU models at all? That sounds convoluted...
> 

Uh? I don't remember anybody suggesting changing CPU models on existing
machines. We always tried to keep existing machines compatible.

> BTW your list does not answer my question. You would need examples where
> a CPU model changes between machines, and I am not aware of any example
> beyond the intentional -x.y variations. There are differences between
> KVM and TCG though, did you mean that? i440fx and q35 should be
> identical and isa-pc, too, and none anyway. None of this has anything to
> do with the host CPU.

We are talking about the -x.y variations (that, yes, are intentional).
But the fact that CPU features change (even the intentional ones in the
-x.y machine variations) affect runnability of VMs (because enabling new
CPU features in KVM require it to be supported by the host kernel code
and by the host CPU).

I was not thinking about the KVM and TCG differences, but this may also
help libvirt deal with the KVM and TCG differences if necessary.

I don't know what you mean by "i440fx and q35 should be identical"
above.

-- 
Eduardo