| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-07-06 | |||
| 16:23:49 | sean-k-mooney | ok so then nova does not need to check for this right | |
| 16:23:52 | bauzas | correct | |
| 16:24:03 | bauzas | that's what we agreed on the spec at least | |
| 16:24:28 | sean-k-mooney | so if livbirt has sev-snp in the lauch capabliteis | |
| 16:24:34 | sean-k-mooney | we should just report the trait | |
| 16:24:39 | bauzas | we don't need to look at the firmware, because even if the firmware can support SNP, the host won't use this until the BIOS is modified | |
| 16:24:45 | sean-k-mooney | and if the operator has not enabeld snp but did create snp flavors | |
| 16:24:52 | sean-k-mooney | then we expect the vm boot to fail | |
| 16:25:13 | gibi | it is about the fact the ES support disappears after that specific firmware upgrade and you can still have ES VMs on thehost | |
| 16:25:19 | bauzas | libvirt provides SNP capabilities only once the BIOS option is modified | |
| 16:25:35 | gibi | the complication is not about SNP, but the disappearence of ES | |
| 16:25:50 | sean-k-mooney | bauzas: ack in that case then we jsut need to look at the libvirt output | |
| 16:25:53 | bauzas | gibi: AFAICU, the ES support continues until the BIOS option is modified, that's my point | |
| 16:26:10 | bauzas | tkajinam: am I right? | |
| 16:26:16 | gibi | if you had a host with both ES and SNP enabled, and then update the firmware, ES disappears without BIOS changes | |
| 16:26:31 | gibi | * BIOS config changes | |
| 16:26:33 | bauzas | because you enabled SNP | |
| 16:26:34 | tkajinam | bauzas, the problem is that /proc/cpuinfo is only the feasible way I could find to detect "the BIOS option is modified" | |
| 16:26:42 | sean-k-mooney | well the sev section has | |
| 16:26:44 | sean-k-mooney | <sev supported='yes'> | |
| 16:26:46 | sean-k-mooney | <cbitpos>51</cbitpos> | |
| 16:26:47 | gibi | bauzas: because you updated the firmware to fix a CVE | |
| 16:26:48 | sean-k-mooney | <reducedPhysBits>1</reducedPhysBits> | |
| 16:26:50 | sean-k-mooney | <maxGuests>500</maxGuests> | |
| 16:26:52 | sean-k-mooney | <maxESGuests>9</maxESGuests> | |
| 16:26:54 | sean-k-mooney | <cpu0Id>LlF/9YPV8hnqsGNCBpLJeRUbm9y/yr5uNhgTaW96/ZVoYXjZRRuIfEwSMFWWd9882pcNDLW6LW3E3tytpU7/2g==</cpu0Id> | |
| 16:26:56 | sean-k-mooney | </sev> | |
| 16:26:59 | sean-k-mooney | the max es gust is still reproted in snp mode | |
| 16:27:17 | sean-k-mooney | but i think we need to look at the combidntion fo the lauchsecurit section and the sev section | |
| 16:27:18 | gibi | beacuse the same set of ASIDs are used for ES and SNP | |
| 16:27:33 | gibi | but a different set used for pure SEV | |
| 16:28:07 | gibi | btw that CVE fix is actually good for us as we don't have to share resources between ES and SNP | |
| 16:28:07 | bauzas | gibi: well, that's another concern, if the operator enabled SNP in the BIOS and then upgraded the firmware due to the CVE, they should know that ES is then disabled automatically | |
| 16:28:20 | gibi | bauzas: | |
| 16:28:37 | bauzas | that's unrelated to nova, right? | |
| 16:28:45 | gibi | but nova has ES VMs on the host :): | |
| 16:28:50 | gibi | so we cannot ignore it | |
| 16:29:11 | tkajinam | bauzas, yes and that's why /proc/cpuflag is checked, because at that point sev-snp is not yet enabled in kvm ( so nova assumes sev-snp is not ready ) | |
| 16:29:15 | bauzas | I think I wrote a spec comment saying about when we restart the compute | |
| 16:29:26 | sean-k-mooney | gibi: do you happen to know if the host you are testing on has the firmware patch | |
| 16:29:38 | bauzas | we can look at the instances and stop the service if we find ES-used instances | |
| 16:29:48 | gibi | it has. It is not possible to boot ES VMs on it | |
| 16:29:51 | gibi | qemu fails | |
| 16:30:01 | tkajinam | https://review.opendev.org/c/openstack/nova/+/994343 | |
| 16:30:08 | sean-k-mooney | ok and does it work with snp disabled | |
| 16:30:10 | tkajinam | this is the actual change where this is being discussed | |
| 16:30:16 | gibi | sean-k-mooney: I don't know that | |
| 16:30:21 | sean-k-mooney | i dont think this is an upgrede concern for nova yet | |
| 16:30:35 | sean-k-mooney | since nova didnt supprot snp before this firmware change | |
| 16:30:43 | gibi | but it did support ES | |
| 16:30:45 | sean-k-mooney | so we just need to document that operator can use oen of the other | |
| 16:30:55 | sean-k-mooney | gibi: right if they flat out broke es with the cve fix | |
| 16:31:03 | tkajinam | so reading actual implementation may give clearer view about the topic. | |
| 16:31:15 | sean-k-mooney | that woudl be a problem but if it works just not when snp is enabeld in teh bios its not an upgrade probvlem | |
| 16:31:20 | gibi | they actaully disabled ES on purpose as when SNP is enabled ES becomes voulnerable | |
| 16:31:31 | bauzas | https://review.opendev.org/c/openstack/nova-specs/+/983376/20..21/specs/2026.2/approved/amd-sev-snp-libvirt-support.rst#b62 | |
| 16:31:37 | sean-k-mooney | sure but as long as you can choose between the two its fine | |
| 16:31:50 | bauzas | so the concern is that we need to look at /proc/cpuinfo ? | |
| 16:31:58 | sean-k-mooney | from a nova point of view we just need to docuemnt that es and snp are mutally exclisive | |
| 16:32:04 | sean-k-mooney | bauzas: yep | |
| 16:32:22 | sean-k-mooney | bauzas: i dont think bypsassing libvirt to look at /proc/cpuinfo is ok | |
| 16:32:31 | bauzas | and there are no other ways to detect a SNP-supported OS ? | |
| 16:32:48 | sean-k-mooney | bauzas: i think that is reported in the launchSecurity section | |
| 16:33:01 | sean-k-mooney | but we woudl have to disabel snp in the bios to confirm | |
| 16:33:07 | sean-k-mooney | and im hesitent to ask gibi to do that | |
| 16:33:07 | bauzas | yeah | |
| 16:33:12 | tkajinam | sean-k-mooney, no launchSecurity does not fully match with sev_snp cpu flag | |
| 16:33:26 | gibi | we agreed in the spec that if we have ES VMs on a host the nova-compute is restarted and sees that no ES capability is available any more due to SNP enabled then nova-compute will fail to start and let the deployer know that there is a mixup of configuration and ask for draining the ES VMs before enabling SNP | |
| 16:33:27 | sean-k-mooney | so its list there whewn its disabeld in the bios | |
| 16:33:28 | tkajinam | sean-k-mooney, for example if you are using an older libvirt then it doesn't have that option but you can enable snp in firmware | |
| 16:33:29 | sean-k-mooney | ? | |
| 16:33:40 | sean-k-mooney | tkajinam: that fine | |
| 16:33:49 | sean-k-mooney | old libivrt is handled by a min version check | |
| 16:33:54 | tkajinam | but that still disables sev-es | |
| 16:34:10 | tkajinam | in hardware level | |
| 16:34:11 | sean-k-mooney | gibi: yep that is the corect behvior | |
| 16:34:40 | sean-k-mooney | its not enfocning that that i object too | |
| 16:35:01 | sean-k-mooney | its how we are determinign that that is problematic | |
| 16:35:42 | bauzas | don't we already look at the cpu capabilities other than using libvirt ? | |
| 16:35:56 | sean-k-mooney | corect we do not | |
| 16:36:02 | bauzas | hmmm | |
| 16:36:13 | antia | does the kernel report sev-es support after firmware update? | |
| 16:36:22 | sean-k-mooney | bauzas: to be clear i was told to go modify libvirt to get feature flags to report in the past more then once | |
| 16:36:27 | tkajinam | bauzas, sean-k-mooney is correct and there is no other logic reading /proc/cpuinfo now | |
| 16:36:44 | bauzas | antia: that depends on the BIOS option AFAICU | |
| 16:36:48 | tkajinam | antia, yes. sev_es cpu flag is still reported, and kvm_amd module still reports sev_es capability | |
| 16:37:11 | bauzas | tkajinam: if the operator didn't set the BIOS SNP option, right ? | |
| 16:37:20 | sean-k-mooney | tkajinam: do you have a host that you are developing this on with the patch | |
| 16:37:26 | tkajinam | bauzas, no, regardless of BIOS setting | |
| 16:37:27 | sean-k-mooney | *with the patched firmware | |
| 16:38:04 | bauzas | I see, of course | |
| 16:38:31 | bauzas | if you set SNP in the BIOS, you will have *both* flags (sev_snp and sev_es) | |
| 16:38:36 | tkajinam | I don't have the one with the said firmware update yet. I'm trying to get full machine time for it but it takes a bit more time. | |
| 16:39:03 | tkajinam | I spent some time looking into kernel and actually sev_es flag is required when sev_snp flag is enabled in kvm_amd | |
| 16:39:20 | tkajinam | so I don't think this behavior (es still reported after snp is enabled in bios) may change quite soon. | |
| 16:40:15 | gibi | so what if we file a bug somewhere in the virt stack, and keep the /proc/cpuinfo check for a while? | |
| 16:40:32 | bauzas | wfm | |
| 16:40:41 | bauzas | with a big TODO/FIXME | |
| 16:40:53 | Uggla | wfm | |
| 16:41:11 | sean-k-mooney | im honestly borderline -2 on /proc/cpuinfo | |