[SOLVED] VM cpu flags usage: which ones should be enabled for max performance and how?

[cosmos]

I'm setting up a Windows Server 2022 VM and noticed these flags. My PVE node is single -> not a part of a cluster, therefore no need to migrate etc. Processor is an Intel Xeon 4208 (IIRC).

From the looks of it, the flags exist to mitigate various CPU-level attacks. Assuming that nothing as such will be running on the VM, I have two questions:
1) which flags can I safely enable
2) how are flags enabled? That is, should I set them to the right, or the left position (each switch has 3 positions)

 

[t.lamprecht]

My PVE node is single -> not a part of a cluster, therefore no need to migrate etc. Processor is an Intel Xeon 4208 (IIRC).

If you do not need to live-migrate you could use the host CPU type, which then gives the VM (almost) the same CPU flags/feature set as the host CPU. I say "almost" because some, e.g., machine specific register (MSR) do not make sense, or would allow stabillity bugs and/or security escalation if the VM could control it.

2) how are flags enabled? That is, should I set them to the right, or the left position (each switch has 3 positions)

If you click the options the text shows what will be done. Left, i.e. where the - is, means always-off, middle is default from QEMU and CPU model and right (+) means always-on.

 

[cosmos]

Hey Thomas, long time no see

I've been using host as the CPU time, it's the flags part that got me confused. So would enabling all flags be ok in this case? Again, no external access will be made on the box, just internal stuff I'm using.

 

[t.lamprecht]

Hi!

So would enabling all flags be ok in this case?

No, some flags are CPU vendor specific and the VM would then not start, those normally mention the vendor name in the description though, so all those with AMD in the name or description are not applicable for your setup here.

And if a flag makes sense and can improve things, or if it might fail to start the VM or make, e.g., performance worse also depends on what OS runs inside the VM, and for Linux also which kernel version and build config was used.

The most relevant ones for the CPU mitigations are documented here:
https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_meltdown_spectre

But with using the host or Cascadelake-Server CPU models you already get those, at least if you did not override the flag by using the always-off switch.

The hv-* ones are mostly relevant for Windows VMs, and there even more so for nested virtualization.

If you got Linux based VMs you could check the lscpu output there to see which flags you already get, if you already use the host type you should be fine.

 

[cosmos]

Great information, thank you!

A bit confusing is the fact that these flags do not operate in the sense that setting them to off improves performance. For example, the aes option, if I understand correctly will decrease if the flag is set to off.

I'll set the following to off: pcid, spec-ctrl, ssbd
And I'm setting the following to on : aes
Do you foresee any stability issues with the above?

 

[t.lamprecht]

A bit confusing is the fact that these flags do not operate in the sense that setting them to off improves performance.

Hmm, not 100% sure what you mean. Most of the flags improve performance by exposing some newer HW feature to the VM that can assist the OS to do some things faster, that's why enabling them can make things faster (almost all of the time, HW and firmware is complex, edge case exist like everywhere)

For example, the aes option, if I understand correctly will decrease if the flag is set to off.

Exactly, because the VM and thus the guest OS does not see the AES related HW accelerations anymore and falls back to some slower software variant.

I'll set the following to off: pcid, spec-ctrl, ssbd

Those should be on too for best performance, and for Host/CascadeLake it might be best to keep them at the default setting.

And I'm setting the following to on : aes

This is fine, albeit IIRC setting it explicitly to on should not be required with CPU type host, default should work fine there.

 

[cosmos]

Hmm, not 100% sure what you mean. Most of the flags improve performance by exposing some newer HW feature to the VM that can assist the OS to do some things faster, that's why enabling them can make things faster (almost all of the time, HW and firmware is complex, edge case exist like everywhere)

Re-read what I wrote and indeed does not make sense From an admin's point of view the way the toggles are setup one might assume that there is some performance-related consistency. That is if the switch is set to the left (off) performance improves, whereas moving it to the right security improves (at a possible performance penalty).

IOW, for an entry level admin like me it would be nice to have legends like better-performance / default / better security perhaps, instead of off / default / enabled. I'm sorry if I don't make sense here, don't know if I can rephrase things better.

Those should be on too for best performance, and for Host/CascadeLake it might be best to keep them at the default setting.

Great, I'll just leave host and the cpu flags to the middle/default setting then.