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

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, Jun 23, 2015 at 11:23:16PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2015 at 05:42:04PM +0100, Daniel P. Berrange wrote:
> > On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
> > > > 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...
> > > > 
> > > > Whether QEMU changed the CPU for existing machines, or only for new
> > > > machines is actually not the core problem. Even if we only changed
> > > > the CPU in new machines that would still be an unsatisfactory situation
> > > > because we want to be able to be able to access different versions of
> > > > the CPU without the machine type changing, and access different versions
> > > > of the machine type, without the CPU changing. IOW it is the fact that the
> > > > changes in CPU are tied to changes in machine type that is the core
> > > > problem.
> > > 
> > > But that's because we are fixing bugs.  If CPU X used to work on
> > > hardware Y in machine type A and stopped in machine type B, this is
> > > because we have determined that it's the right thing to do for the
> > > guests and the users. We don't break stuff just for fun.
> > > Why do you want to bring back the bugs we fixed?
> > 
> > Huh, I never said we wanted to bring back bugs. This is about allowing
> > libvirt to fix the CPU bugs in a way that is independant of the machine
> > types and portable across hypervisors we deal with. We're absolutely
> > still going to fix CPU model bugs and ensure stable guest ABI.
> > 
> > Regards,
> > Daniel
> 
> So any single CPU flag now needs to be added in
> - kvm
> - qemu
> - libvirt
> 
> Next thing libvirt will decide it's a policy thing and so
> needs to be pushed up to openstack.

I don't think that will happen, but if they really decide do do it, why
should we try to stop them? libvirt and OpenStack know what their users
do/need better than us, and if they believe moving data to OpenStack
will provide what users need, they are free to do it. I trust libvirt
developers to do the right thing, here.

> 
> We should just figure out what you want to do and support it in QEMU.
> 
> Are there many examples where a single flag used to work and then
> stopped? I would say such a change is problematic anyway:
> not everyone uses libvirt, you are breaking things for people
> that run -M pc.

People using -M pc have to live with the fact that the host-side
requirements of -M pc may change in newer QEMU versions.

(Again, this is not about ABI changes, but about adding new host-side
hardware/kernel requirements to make a VM run)

> 
> IMHO -M pc is not supposed to mean "can break at any time".

It means "it may have new host-side requirements and may become runnable
in your host (or require additional command-line flags to run) at any time".

-- 
Eduardo