From: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
To: David Hildenbrand <david@redhat.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: Wed, 25 Oct 2017 18:45:51 +0200 [thread overview]
Message-ID: <87wp3jqips.fsf@marc-ibm.boeblingen.de.ibm.com> (raw)
In-Reply-To: <a7b30204-a854-afde-af01-234520cc6d7b@redhat.com>
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?
>
> 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
next prev parent reply other threads:[~2017-10-25 16:46 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 [this message]
2017-10-26 8:09 ` David Hildenbrand
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=87wp3jqips.fsf@marc-ibm.boeblingen.de.ibm.com \
--to=mhartmay@linux.vnet.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=fiuczy@linux.vnet.ibm.com \
--cc=jdenemar@redhat.com \
--cc=jjherne@linux.vnet.ibm.com \
--cc=libvir-list@redhat.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).