qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
To: David Hildenbrand <david@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Marc Hartmayer <mhartmay@linux.vnet.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 17:09:28 +0200	[thread overview]
Message-ID: <9f4037d8-93a3-be0f-8cb4-4424158e236b@linux.vnet.ibm.com> (raw)
In-Reply-To: <1ac27ce2-091d-e1b7-fc94-ebdf696a35e9@redhat.com>

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.

Regarding the libvirt side of this:
When looking at https://libvirt.org/formatdomain.html#elementsCPU I 
found the following sentence:
Since the CPU definition is copied just before starting a domain, 
exactly the same XML can be used on different hosts while still 
providing the best guest CPU each host supports.

My interpretation of "the best guest CPU each host supports" is that 
besides limiting factors like hardware, kernel and qemu capabilities the 
requested machine type for the guest is a limiting factor as well.

Nevertheless if my interpretation is found to be incorrect than we 
should think about another new cpu mode that includes the machine type 
into the "best guest CPU" detection.
My assumption is that we must not require the users to know which cpu 
model they manually need to define to match a specific machine type
AND we want to guarantee that guests run without risking any side 
effects by tolerating any additional cpu features.

-- 
Mit freundlichen Grüßen/Kind regards
    Boris Fiuczynski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

  reply	other threads:[~2017-10-25 15:09 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 [this message]
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
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=9f4037d8-93a3-be0f-8cb4-4424158e236b@linux.vnet.ibm.com \
    --to=fiuczy@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.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).