qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Not introducing new host-side requirements on new machi


From: Eduardo Habkost
Subject: Re: [Qemu-devel] Not introducing new host-side requirements on new machine-type versions (was Re: [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models)
Date: Wed, 24 Jun 2015 13:08:52 -0300
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Jun 24, 2015 at 05:58:18PM +0200, Andreas Färber wrote:
> Am 24.06.2015 um 17:44 schrieb Eduardo Habkost:
> > In another message, Paolo wrote:
> >> libvirt should trust that QEMU developers will not prevent a VM from
> >> running on a previously viable host, just because you change the machine
> >> type.
> > 
> > I assumed that was never going to be true.
> > 
> > As long as QEMU guarantees that, so we don't change existing CPU models
> > (in new machines) in a way that introduces new host-side dependencies,
> > we will be OK.
> > 
> > We may need something new to implement this guarantee for KVM features,
> > though. libvirt will need something that says "please don't enable any
> > KVM CPUID bits silently for me, let me ask for them explicitly". But
> > that won't be as drastic as requiring "-cpu custom".
> 
> That's what I suggested a global property for yesterday. Not sure how it
> would be implemented though.

A "default-kvm-features" property that enables/disables loading of
kvm_default_features would be enough, probably.

> 
> > That have some consequences in the way we add new CPU models and
> > implement CPU model changes. For example: until we know all the features
> > we want in a CPU model are already available and supported in the latest
> > kernel, we won't add a new CPU model. The choice of features in CPU
> > models should be "final" as soon as we add the CPU model, so CPU model
> > changes should never introduce new host-side requirements. If a CPU
> > model change requires some additional KVM code or newer host CPU, we
> > need to add a new CPU model name. We must agree on that and document it,
> > because I expect to see some complaints in the future when enforcing
> > this rule.
> > 
> >>
> >> It's as if someone wrote a wrapper around all kernel system calls
> >> on the assumption that kernel can not guarantee kernel/userspace ABI
> >> will never change. It can and it does.
> >>
> >> So let's promise not to break things, and avoid a ton of copy and paste 
> >> bugs.
> > 
> > My assumption was that this (introducing type-(2) machine changes) was
> > never considered "breaking things" and just a fact of life.
> > 
> > If we guarantee that we will never prevent a VM from running on a
> > previously viable host, just because you change the machine type, we
> > will be OK.
> 
> Could you clarify whether that is for KVM only or in general?
> 
> Also, if we ignore qemu64 and pick a current X86CPU such as Haswell, can
> you make a list of features that are missing in our model and in KVM, if
> any, and might be enabled in future Haswell / Haswell+X models? What
> delta are we talking about exactly?

We can make a list by comparing CPUID data from the guest/QEMU with the
real host CPUID data. But I believe we don't have any features we expect
to enable in the future in existing CPU models that would require new
KVM-side code. We just need to be aware of this in the (unlikely?) case
it happens.

Note that the recent ARAT patches are OK because they don't depend on
new KVM-side GET_SUPPORTED_CPUID changes to work.

> 
> Are we at the same point of stability guarantee for ppc POWER?
> For s390x, arm and aarch64 I guess not yet?

That's a good question, and I have no idea how difficult it would be to
implement that guarantee in those machines.

In s390x we are implementing machine-type-dependent "runnable" info on
query-cpu-definitions, but I don't know what the use caes look like, and
what are the consequences for libvirt and OpenStack.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]