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 v3 qemu-server 1/7] cpuconfig: add new x86-64-vX models
Date: Thu, 1 Jun 2023 11:27:45 +0000 [thread overview]
Message-ID: <7948b371bf9601f6389a1f74790768b0fbbe8e12.camel@groupe-cyllene.com> (raw)
In-Reply-To: <dfae9114-b8f2-f690-23a2-30c132477194@proxmox.com>
Le jeudi 01 juin 2023 à 11:17 +0200, Fiona Ebner a écrit :
> Am 31.05.23 um 17:08 schrieb DERUMIER, Alexandre:
> > > >
> > > > +my $builtin_models = {
> > > > + 'x86-64-v1' => {
> > > > + 'reported-model' => 'Opteron_G1',
> > >
> > > It's unfortunate that we'll report this model and hence also AMD
> > > as
> > > vendor even on Intel hosts and vice versa for the other models.
> > > We
> > > could
> > > set the vendor to the host's vendor (in get_cpu_options() handle
> > > getting
> > > the vendor for the built-in models differently),
> > I think it'll break if you migrate between intel/amd host anyway ?
>
> That's true :)
>
> > > but that's also
> > > strange, because then it would be Opteron_G1 with vendor
> > > GenuineIntel
> > > :/
> > > So maybe better to just leave it?
> > Well, kvm64 guest have vendor Authentic amd (even on intel host;),
> > with
> > modelname "common kvm processor")
> > cat /proc/cpuinfo
> > vendor_id : AuthenticAmd
> > model name : "Common KVM processor"
>
> Are you sure? Or was this a migrated machine?
>
> We have this comment
>
> > # generic types, use vendor from host node
> > host => 'default',
> > kvm32 => 'default',
> > kvm64 => 'default',
>
> and for a colleague, it is GenuineIntel with kvm64 on an Intel host.
>
oh, you are right, it's indeed inherit the vendorid from the host
(tested with kvm64 && qemu64).
Maybe they are some specific trick for theses model in qemu
(because in cpu definition, the vendor is really intel for kvm64 && amd
for qemu64. Maybe they are some other part in code to inherit from the
host vendor)
https://github.com/qemu/qemu/blob/master/target/i386/cpu.c
> > If we don't want to expose the original modelname from where we
> > derivate, afaik, the only way is to patch qemu directly (like in my
> > v1).
>
> We can actually just use the model-id option for -cpu and I think we
> should for these built-in models. I.e. set the vendor to the one from
> the host and the model-id to something generic too. Maybe "Common
> x86_64-abi1-compatible processor", but that feels involved, or maybe
> just "Common KVM processor" again?
ah ok, i wasn't aware of model-id. don't have preference, can be
"Common KVM processor" or "specific version".
just tested it, vendor can also be specified
",model-id="Common KVM processor",vendor=GenuineIntel"
(I think it shouldn't break live migration if it's working with kvm64,
I think that vendor is not changing until the guest is restart.)
>
> > >
> > > > + flags => "-vme;-svm;-vmx",
> > >
> > > Why remove the svm and vmx flags? They are not exposed by us, so
> > > a
> > > user
> > > cannot even enable them back if needed, but needs to switch to a
> > > different CPU type.
> > yes, that's was the idea to forbid user to enable them, as it's
> > breaking livemigration, so it don't make any sense to use this
> > model
> > instead host model.
> >
> > But I can remove them, no problem.
>
> Oh, I missed the following in the referenced mail:
>
> > None of the CPU models declare any VMX/SVM capability features.
> > IOW, even if a "vmx"/"svm" flag is added, it will still be unsafe
> > to attempt to live migrate the L1 guest if there are any L2
> > guests running with hardware virtualization.
>
> Please keep them off then.
>
ok, no problem
> > > > @@ -96,6 +115,9 @@ my $cpu_vendor_list = {
> > > > kvm64 => 'default',
> > > > qemu32 => 'default',
> > > > qemu64 => 'default',
> > > > + 'x86-64-v1' => 'default',
> > > > + 'x86-64-v2' => 'default',
> > > > + 'x86-64-v3' => 'default',
> > >
> > >
> > > Currently all of the others are actual models we can pass
> > > directly to
> > > QEMU/KVM. I'd rather not add these custom built-in ones here.
> > > You'll
> > > need to adapt validate_vm_cpu_conf() of course, to also accept
> > > the
> > > built-in ones.
> > >
> > > Because of adding them here, I can also set them as the
> > > 'reported-
> > > model'
> > > for a custom CPU in /etc/pve/virtual-guest/cpu-models.conf and
> > > parsing
> > > the file will work, but then starting a VM with that custom CPU
> > > will
> > > fail with kvm: unable to find CPU model 'x86-64-v1'.
> > >
> > > If we'd like to enable using the built-in ones as base for custom
> > > CPU
> > > models, we'll need to handle them differently, but I'm not sure
> > > we
> > > should until there is enough user demand.
> > >
> > Maybe it could be simplier to really add true build-model in qemu ?
> > (The qemu patch is pretty small, and shouldn't be difficult to
> > maintain)
> >
> > I'm not sure, but maybe user will think that it's strange than x86-
> > 64-
> > v2 will display nahelem in guest && in qemu command line ?
> >
>
> Yes, for this it would be easier, but I also don't think we need to
> allow these as a base for custom models (at least not until there is
> enough user demand). And we can still switch later to make them true
> QEMU models if we really need to.
>
ok,no problem, I'll rework my patch with model/vendor and all your
comments.
Thanks for your review !
next prev parent reply other threads:[~2023-06-01 11:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 10:25 [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 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 [this message]
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
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=7948b371bf9601f6389a1f74790768b0fbbe8e12.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