| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-07-06 | |||
| 17:09:45 | opendevreview | Takashi Kajinami proposed openstack/nova master: Remove [libvirt] num_memory_encrypted_guests https://review.opendev.org/c/openstack/nova/+/995120 | |
| 17:17:40 | opendevreview | Merged openstack/nova master: Add concurrency_backend config option for Nova services https://review.opendev.org/c/openstack/nova/+/993760 | |
| 18:30:43 | opendevreview | Takashi Kajinami proposed openstack/nova master: Fix wrong comment in test https://review.opendev.org/c/openstack/nova/+/996070 | |
| #openstack-nova - 2026-07-07 | |||
| 07:29:04 | gibi | tkajinam: I will try to collect as much printouts as possible form my HW today from both SNP enabled and SNP disabled in BIOS mode to see if we can settle the yesterdays debate somehwo | |
| 07:30:08 | bauzas | gibi: thanks that will help | |
| 07:30:48 | gibi | then I will have to give the HW back | |
| 07:30:58 | gibi | probably I can ask for it again later if needed | |
| 07:31:14 | bauzas | the issue is with the SNP support detection that said, as tkajinam said, atm we only be able to look at the /proc/cpuinfo file | |
| 07:31:15 | gibi | but I don't want to overstretch the kindness of the kernel folks :) | |
| 07:35:37 | bauzas | heh sure | |
| 07:36:01 | bauzas | gibi: I mean, if you can see how we can detect by libvirt whether we support SNP, it would be nice | |
| 07:36:51 | gibi | I think there is an extra complication about libvirt version which I cannot really test. I will have data from one specific libvirt version 12.5 | |
| 07:39:52 | gibi | I can try to get back to libvirt 11.10 but I cannot go back to 10.5 | |
| 07:47:36 | bauzas | ack thanks | |
| 08:00:06 | opendevreview | Kamil Sambor proposed openstack/nova master: Correct release name in concurrency_backend https://review.opendev.org/c/openstack/nova/+/996219 | |
| 08:32:19 | gibi | tkajinam, sean-k-mooney: here are data collected from my HW with SNP enabled and disabled in BIOS. https://drive.google.com/drive/folders/1U_wK6DRiPxKm98LJx3_BGH3VTEsPtFSU?usp=drive_link | |
| 08:33:30 | sean-k-mooney | i cannot downlowd those files | |
| 08:33:33 | gibi | the most useful thing seems to be /sys/module/kvm_amd/parameters/sev_snp as that switches to N when I disable the feature in BIOS | |
| 08:33:50 | sean-k-mooney | oh i might need to sign in | |
| 08:34:25 | gibi | I can open them in incognito | |
| 08:35:33 | sean-k-mooney | i had to down load the full set | |
| 08:35:38 | sean-k-mooney | but then i coudl open the zip | |
| 08:35:49 | sean-k-mooney | so <launchSecurity supported='yes'> | |
| 08:35:51 | sean-k-mooney | <enum name='sectype'> | |
| 08:35:53 | sean-k-mooney | <value>sev</value> | |
| 08:35:55 | sean-k-mooney | <value>sev-snp</value> | |
| 08:35:57 | sean-k-mooney | </enum> | |
| 08:35:59 | sean-k-mooney | </launchSecurity> | |
| 08:36:02 | sean-k-mooney | is till advertised in the non snp libvirt folder | |
| 08:36:14 | sean-k-mooney | so that with snp disabled in the bios? | |
| 08:36:55 | bauzas | that's the problem tkajinam mentioned yesterday | |
| 08:37:17 | bauzas | libvirt says "sure, do SNP" even if the BIOS option is disabled | |
| 08:37:38 | sean-k-mooney | right but that isnt something nova should be checking | |
| 08:37:44 | bauzas | maybe this is fixed in a later libvirt release tho | |
| 08:37:48 | sean-k-mooney | that shoudl be either a config option or soemthing libvirt tells us | |
| 08:38:24 | bauzas | would you be OK with a nova conf asking the operator to set it once the BIOS option is set ? | |
| 08:38:35 | sean-k-mooney | yes | |
| 08:38:54 | bauzas | and by default, saying no | |
| 08:39:08 | gibi | the non_snp folder is the one where I disable the snp in bios, yes | |
| 08:39:10 | sean-k-mooney | i woudl also be ok with it beign a comma seperate list of sev modes | |
| 08:39:25 | sean-k-mooney | sev_mdoes=sev,sev-snp | |
| 08:39:50 | sean-k-mooney | gibi: is there a reason you downgraded back to 11.10? | |
| 08:42:32 | sean-k-mooney | bauzas: the minimal change i woudl be ok with is not parsing and extracting all the cpu flags and then check if sev-snp is in it and instead jsut check for that one value. i.e. i dont like that we are adding self._cpu_flag and now have a thrid set of cpu flag in the libvirt driver | |
| 08:42:55 | sean-k-mooney | we are already mixing the cpu flags form virsh capablities and domcapablites which are not the saem | |
| 08:43:20 | sean-k-mooney | and parsing and storage all the raw cpu flags woudl add a third set that disagree with the other two | |
| 08:44:53 | sean-k-mooney | gibi are you suggesting we use /sys/module/kvm_amd/parameters/sev Y /sys/module/kvm_amd/parameters/sev_es Y /sys/module/kvm_amd/parameters/sev_snp N | |
| 08:44:55 | sean-k-mooney | instead | |
| 08:45:15 | sean-k-mooney | i slightly prefer that over parsing /proc also | |
| 08:45:49 | sean-k-mooney | so if we use read_sys form the filesytem module to check /sys/module/kvm_amd/parameters/sev_snp and use that to set _support snp | |
| 08:46:18 | sean-k-mooney | and do the same for the other two parmater so we set all 3 booleans the same way that coudl be workable | |
| 08:46:51 | sean-k-mooney | its unfortente that the snp enabeld host has | |
| 08:46:53 | sean-k-mooney | /sys/module/kvm_amd/parameters/sev Y /sys/module/kvm_amd/parameters/sev_es Y /sys/module/kvm_amd/parameters/sev_snp Y | |
| 08:47:14 | sean-k-mooney | becasue it mean nova need to knwo about the new fireware bevhior which it really should not need to knwo about | |
| 08:48:29 | sean-k-mooney | hum | |
| 08:48:32 | sean-k-mooney | [ 17.742507] ccp 0000:23:00.1: SEV firmware updated from 1.55.31 to 1.58.1 | |
| 08:48:50 | sean-k-mooney | so you r firmware is bing updated during boot | |
| 08:49:06 | sean-k-mooney | i wonder if that is also impacting this behvior | |
| 08:50:05 | sean-k-mooney | i was hoping or at least expect /sys/module/kvm_amd/parameters/sev_es N | |
| 08:50:16 | sean-k-mooney | when snp is enabeld in the bios | |
| 08:51:25 | sean-k-mooney | i wonder if that will be fixed ina future kernel update but in any case reading /sys/module/kvm_amd/parameters/sev_snp is less prblematic to me then /proc/cpuinfo | |
| 08:51:31 | sean-k-mooney | tkajinam: ^ | |
| 08:52:13 | gibi | so based on my trial, if SNP is disable in the bios then we can start ES VMs. So if we only rely on /sys/module/kvm_amd/parameters/sev_snp to detect in SNP is enabled in the bios that would be enough to infer if ES can be used or not. | |
| 08:53:28 | sean-k-mooney | looking at the data sev_snp is in /proc/cpuinfo on the host with it disabeld in the bios | |
| 08:53:46 | sean-k-mooney | so looking at that does not help in this case | |
| 08:54:47 | sean-k-mooney | /sys/module/kvm_amd/parameters/sev_snp really does seam to be the only thing that tells us the bios config state | |
| 08:55:24 | bauzas | gibi: two negatives in your last phrase didn't help me, you mean that checking sev_snp in sysfs can be enough for knowing whether the host supports SNP or ES ? | |
| 08:55:41 | sean-k-mooney | bauzas: yes ^ | |
| 08:56:01 | sean-k-mooney | bauzas: if /sys/module/kvm_amd/parameters/sev_snp is Y we know we cant use ES | |
| 08:56:16 | bauzas | confirmed ? | |
| 08:56:28 | gibi | by looking at the /sys/module/kvm_amd/parameters/sev_snp if that is N, and sev_es is Y, then I can boot SEV ES VMs on the machine | |
| 08:56:45 | gibi | if both is yes then on SEV SNP can be booted | |
| 08:56:55 | gibi | *both is Y | |
| 08:57:00 | gibi | *both are Y | |
| 08:57:15 | sean-k-mooney | *then only | |
| 08:57:17 | bauzas | OK, and when SNP BIOS option is disabled, then /sys/module/kvm_amd/parameters/sev_snp is N ? | |
| 08:57:44 | bauzas | (with new firmware of course) | |
| 08:57:47 | gibi | /sys/module/kvm_amd/parameters/sev Y /sys/module/kvm_amd/parameters/sev_es Y /sys/module/kvm_amd/parameters/sev_snp N | |
| 08:57:59 | bauzas | perfect then | |
| 08:58:15 | gibi | all given with the kernel verson I run (6.12) | |
| 08:58:18 | bauzas | tkajinam: looks like we have an alternative | |
| 08:58:32 | bauzas | gibi: yeah, of course | |
| 08:58:35 | gibi | this is the firmware version microcode_ctl-20260210-1.el10.noarch | |
| 08:59:07 | sean-k-mooney | bauzas: well its not jsut an alternitive the curent patch that looks at /proc/cpuinfo is incorrect | |
| 08:59:40 | sean-k-mooney | bauzas: looking at the data that gibi collected sev_snp is alwasy in /proc/cpuinfo regardless fo the bios option | |
| 09:00:21 | sean-k-mooney | so we can check if the host could supprot snp by checking lauchsecuity for <value>sev-snp</value> | |
| 09:00:29 | sean-k-mooney | and we can check if its congiured ot use it | |
| 09:00:36 | sean-k-mooney | by checkign /sys/module/kvm_amd/parameters/sev_snp | |
| 09:01:24 | sean-k-mooney | so we would report snp support if an only if /sys/module/kvm_amd/parameters/sev_snp Y and launchsecuirt <value>sev-snp</value> | |
| 09:01:53 | sean-k-mooney | if /sys/module/kvm_amd/parameters/sev_snp Y we will not report es supprot | |
| 09:02:51 | bauzas | hah | |
| 09:03:20 | bauzas | I was thinking /proc/cpuinfo was correct, but if that's not, then yeah indeed this is even not an alternative | |
| 09:04:23 | sean-k-mooney | i think /proc/cpuinfo is basiclly checkign the cpuid bits and decoding them, indepently of the fireware state | |
| 09:05:09 | sean-k-mooney | so its baiclly sayign "this cpu implents this feature" not that you can use it at least in this kernle version | |
| 09:05:14 | gibi | (to be correct I haev | |
| 09:05:23 | gibi | (to be correct I have amd-ucode-firmware-20260624-24.el10.noarch | |
| 09:05:29 | gibi | that has the firmware | |
| 09:05:41 | gibi | SEV > than 1.37.23 has the fix | |
| 09:05:55 | gibi | and I'm running 1.58.1 based on dmestg | |
| 09:06:58 | gibi | > 10:39 < sean-k-mooney> gibi: is there a reason you downgraded back to 11.10? | I wanted to see if libvirt reporting changed between these versions | |
| 09:07:26 | sean-k-mooney | ack i just didn see a no snp 12.x data | |