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: Andreas Färber
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 17:58:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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.

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

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

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)



reply via email to

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