qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>,
	Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>
Cc: libvir-list@redhat.com, qemu-devel@nongnu.org,
	Jiri Denemark <jdenemar@redhat.com>,
	"Jason J . Herne" <jjherne@linux.vnet.ibm.com>,
	Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>,
	Halil Pasic <pasic@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
Date: Thu, 26 Oct 2017 10:09:46 +0200	[thread overview]
Message-ID: <04fe8f34-6f23-93d4-f388-ad7f03a24ca7@redhat.com> (raw)
In-Reply-To: <87wp3jqips.fsf@marc-ibm.boeblingen.de.ibm.com>

On 25.10.2017 18:45, Marc Hartmayer wrote:
> On Wed, Oct 25, 2017 at 05:50 PM +0200, David Hildenbrand <david@redhat.com> wrote:
>> On 25.10.2017 17:09, Boris Fiuczynski wrote:
>>> On 10/25/2017 12:23 PM, David Hildenbrand wrote:
>>>> On 25.10.2017 12:18, Christian Borntraeger wrote:
>>>>> Ping, I plan to submit belows patch for 2.11. We can then still look into
>>>>> a libvirt<->qemu interface for limiting host-model depending on machine versions
>>>>> (or not).
>>>>
>>>> I think this would be sufficient for now.
>>>>
>>>> Having different host models, depending on the the machine type sounds
>>>> wrong. But maybe we'll need it in the future.
>>>>
>>>
>>> David, I disagree if your proposal is to generally tolerate new cpu
>>> features in old machine types. This *might* work for gs but how do you
>>> guaranty that guests do not behave differently/wrong when suddenly new
>>> cpu features are made available to guest when (re-)starting them.
>>> That is my feedback for the qemu side of this mater.
>>
>> Just re-reading this section, so what you mean is:
>>
>> a) guest is started, host model is copied and used. guest works.
>> b) guest is stopped.
>> c) QEMU/KVM/HW is updated.
>> d) guest is started, new host model is copied. guest no longer works.
>>
>> d) could be because there are now some additional features with e.g.
>> broken guest implementation or now missing features.
>>
>>
>> What you propose (if I am not wrong) is a to bind features somehow to a
>> QEMU machine. I think that should never be done. You could not catch now
>> missing features.
> 
> What exactly do you mean by the last sentence?

In general, up/downgrading QEMU/KVM/HW can lead to the removal of features.

Another example is the "nested" flag for KVM. toggling that can lead to
the host feature looking differently (+/- SIE features).

So if you really want to make sure that a VM XML that once ran perfectly
fine on a host will still run after any QEMU/KVM/HW changes on that host:

a) specify an explicit CPU model, not the host model (e.g. "z13")
b) copy the host model to the XML persistently.

Linking any of that to the machine types is in my opinion the very wrong
approach.

> 
>>
>> What would you think about a persistent host-model copy option? So
>> instead of copying at every start, only copy and replace it once in the XML?
>>
>> Easy to specify by the user and no CPU feature changes will happend
>> "blindly".
>>
>>
>> --
>>
>> Thanks,
>>
>> David
>>
> --
> Beste Grüße / Kind regards
>    Marc Hartmayer
> 
> IBM Deutschland Research & Development GmbH
> Vorsitzende des Aufsichtsrats: Martina Koederitz
> Geschäftsführung: Dirk Wittkopp
> Sitz der Gesellschaft: Böblingen
> Registergericht: Amtsgericht Stuttgart, HRB 243294
> 


-- 

Thanks,

David

  reply	other threads:[~2017-10-26  8:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-20 14:54 [Qemu-devel] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines Christian Borntraeger
2017-10-20 15:30 ` Christian Borntraeger
2017-10-25 10:18 ` Christian Borntraeger
2017-10-25 10:23   ` David Hildenbrand
2017-10-25 15:09     ` Boris Fiuczynski
2017-10-25 15:30       ` David Hildenbrand
2017-10-25 15:50       ` David Hildenbrand
2017-10-25 16:45         ` Marc Hartmayer
2017-10-26  8:09           ` David Hildenbrand [this message]
2017-10-27 10:16             ` Jiri Denemark
2017-10-25 18:13 ` Jason J. Herne
2017-10-27 12:31   ` Halil Pasic
2017-10-27 12:42     ` Christian Borntraeger
2017-10-27 13:31       ` Cornelia Huck
2017-10-27 13:47         ` Halil Pasic
2017-10-27 12:45     ` [Qemu-devel] [libvirt] " Christian Borntraeger
2017-10-27 12:57       ` Christian Borntraeger
2017-10-27 13:40         ` Halil Pasic
2017-10-27 14:06           ` Christian Borntraeger
2017-10-27 15:18             ` Halil Pasic
2017-10-27 17:12               ` Jiri Denemark
2017-10-27 18:01                 ` Halil Pasic
2017-10-25 23:35 ` [Qemu-devel] " Halil Pasic
2017-10-26  8:13   ` Christian Borntraeger
2017-10-26 10:43     ` Halil Pasic
2017-10-26  8:17 ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=04fe8f34-6f23-93d4-f388-ad7f03a24ca7@redhat.com \
    --to=david@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=fiuczy@linux.vnet.ibm.com \
    --cc=jdenemar@redhat.com \
    --cc=jjherne@linux.vnet.ibm.com \
    --cc=libvir-list@redhat.com \
    --cc=mhartmay@linux.vnet.ibm.com \
    --cc=mihajlov@linux.vnet.ibm.com \
    --cc=pasic@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).