qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).