public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>,
	"aderumier@odiso.com" <aderumier@odiso.com>,
	"f.ebner@proxmox.com" <f.ebner@proxmox.com>
Subject: Re: [pve-devel] [PATCH-SERIES v3 qemu-server/manager/common] add and set x86-64-v2 as default model for new vms and detect best cpumodel
Date: Thu, 1 Jun 2023 21:15:42 +0000	[thread overview]
Message-ID: <d1570c2d3bebf314851fc61bb90ee579f5945da9.camel@groupe-cyllene.com> (raw)
In-Reply-To: <a6758da8-c507-a909-f4fa-0dad6f7c0255@proxmox.com>

Hi,
I found an interesting thread on the forum about kvm_pv_unhalt

https://forum.proxmox.com/threads/live-migration-between-intel-xeon-and-amd-epyc2-linux-guests.68663/


Sounds good. Please also take a look at the default flag
"kvm_pv_unhalt". As I mentioned, it would cause a kernel crash in
paravirtualized unhalt code sooner or later in a migrated VM (started
on Intel, migrated to AMD).

Please note that according to our tests simply leaving the CPU type
empty in the GUI (leading to the qemu command line argument of -cpu
kvm64,+sep,+lahf_lm,+kvm_pv_unhalt,+kvm_pv_eoi,enforce), while
seemingly working at first, will after some load and idle time in the
VM result in a crash involving kvm_kick_cpu function somewhere inside
of the paravirtualized halt/unhalt code. Linux kernels tested ranged
from Debian's 4.9.210-1 to Ubuntu's 5.3.0-46 (and some in between).
Therefore the Proxmox default seems to be unsafe and apparently the
very minimum working command line probably would be args: -cpu
kvm64,+sep,+lahf_lm,+kvm_pv_eoi.




So,it sound like it's crash if it's defined with a cpu vendor not
matching the real hardware ?

as it's break migration between intel && amd, maybe we shouldn't add
it to the new x86-64-vx model ?



a discussion on qemu-devel mailing is talking about performance
with/witout it
https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg01816.html

and it's seem to help when you have a lot of cores/numa nodes in guest,
but can slowdown small vms. 


  reply	other threads:[~2023-06-01 21:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22 10:25 Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 1/7] cpuconfig: add new x86-64-vX models Alexandre Derumier
2023-05-31 11:08   ` Fiona Ebner
2023-05-31 15:08     ` DERUMIER, Alexandre
2023-06-01  9:17       ` Fiona Ebner
2023-06-01 11:27         ` DERUMIER, Alexandre
2023-05-22 10:25 ` [pve-devel] [PATCH v2 pve-manager 1/1] qemu: processor : set x86-64-v2 as default cputype for create wizard Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH pve-common 1/1] read_cpuinfo: add msr support Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 2/7] cpumodel: add cpu models with flags Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 3/7] cpumodel: compute qemu supported flags Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 4/7] cpuconfig: add get_host_cpu_flags Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 5/7] cpuconfig: add find_best_cpumodel Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 6/7] cpuconfig: add find_hosts_common_flags Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 7/7] add best cpu model detection tests Alexandre Derumier
2023-05-31 11:36 ` [pve-devel] [PATCH-SERIES v3 qemu-server/manager/common] add and set x86-64-v2 as default model for new vms and detect best cpumodel Fiona Ebner
2023-05-31 14:34   ` DERUMIER, Alexandre
2023-06-01  8:34     ` Fiona Ebner
2023-06-01  9:06       ` DERUMIER, Alexandre
2023-06-03 14:14         ` Thomas Lamprecht
2023-06-04  6:29           ` DERUMIER, Alexandre
2023-06-03 14:05       ` Thomas Lamprecht
2023-06-01  9:34 ` Fiona Ebner
2023-06-01 11:37   ` DERUMIER, Alexandre
2023-06-01 13:53     ` DERUMIER, Alexandre
2023-06-01 15:56       ` Fiona Ebner
2023-06-01 21:15         ` DERUMIER, Alexandre [this message]
2023-06-02  7:28           ` Fiona Ebner
2023-06-02  9:13             ` DERUMIER, Alexandre
2023-06-02 11:13               ` Fiona Ebner
2023-06-02 11:44                 ` DERUMIER, Alexandre
2023-06-03 14:21               ` Thomas Lamprecht
     [not found]     ` <8277a27b-a70f-b731-69f7-fc9ae69b2da2@binovo.es>
2023-06-01 16:00       ` Fiona Ebner
2023-06-02 12:41         ` Aaron Lauterer
2023-06-02 14:15           ` DERUMIER, Alexandre
2023-06-02 16:09             ` Aaron Lauterer
2023-06-02 16:27               ` DERUMIER, Alexandre
     [not found]         ` <fa3565e5-3a9c-9348-f291-554a0e0d6628@binovo.es>
2023-06-06  9:15           ` Fiona Ebner

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=d1570c2d3bebf314851fc61bb90ee579f5945da9.camel@groupe-cyllene.com \
    --to=alexandre.derumier@groupe-cyllene.com \
    --cc=aderumier@odiso.com \
    --cc=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal