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.
> 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?
>>
>>> + 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.
>>> @@ -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.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
