| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-07-06 | |||
| 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 | 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: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: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 | bauzas | yeah | |
| 16:33:07 | sean-k-mooney | and im hesitent to ask gibi to do that | |
| 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 | |
| 16:41:20 | sean-k-mooney | unless we replace usign libvirt for that in generla | |
| 16:41:32 | sean-k-mooney | i really dont think that is correct | |
| 16:42:05 | gibi | but as far as I see we don't have an alternative at the moment | |
| 16:42:24 | tkajinam | there is still an option not to detect partial sev-snp configuration, and just fail only when sev-snp is flly configured | |
| 16:42:39 | sean-k-mooney | we have at leat one check to do which is detemin if the lauch securit section chagnes in reponce to the bios chagne | |
| 16:42:44 | sean-k-mooney | and we can have a config option for it | |
| 16:42:47 | tkajinam | I mean, compute may not fail only when snp is enabled in BIOS, but then fails if operators try to enable snp fully. | |
| 16:43:01 | gibi | tkajinam: but ES VM still fail | |
| 16:43:02 | sean-k-mooney | the same way we had a config option for the number of sev isntance that can be coreated | |
| 16:43:05 | sean-k-mooney | *created | |
| 16:43:05 | gibi | in the partial config | |
| 16:43:11 | sean-k-mooney | until we fixed libvirt | |
| 16:43:11 | tkajinam | gibi, yes | |
| 16:43:43 | gibi | I rather keep that ~10 lines of code in nova than partially detect the a failure | |
| 16:44:22 | gibi | the config option route does not apply in my mind as the deployer probably don't know that snp disables es in the hardware otherwise he would drain the ES VMs already | |
| 16:44:25 | gibi | so config is unreliable | |
| 16:44:45 | sean-k-mooney | but the operator should know that | |
| 16:45:02 | gibi | then we don't need the nova-compute startup check at all | |
| 16:45:08 | gibi | as operator knows and drains :) | |