Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-07-07
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
09:07:30 sean-k-mooney i assume it didnt change
09:07:53 sean-k-mooney gibi: are you happy to summerise your finding and this conversation on the review?
09:08:54 gibi yepp I'm adding it
09:10:41 bauzas thanks
09:28:41 gibi summarized to https://review.opendev.org/c/openstack/nova/+/994343/12#message-58d4e2f443634207d5a35a5cefce1fbd31ede5b8
09:54:53 opendevreview Joan Gilabert proposed openstack/nova master: Add libvirt driver MDEV ARQ support for Cyborg https://review.opendev.org/c/openstack/nova/+/995840
12:20:56 gibi I'm returning the HW
12:38:16 tkajinam gibi sean-k-mooney bauzas , sorry I was out during the way and am catching up. I read the test result posted by gibi and I agree cpuinfo does not really working as expected (I picked it up from my old test logs but I might have misread it after a while).
12:38:36 tkajinam I'll update the implementation and also spec to reflect the change soon.
12:39:14 sean-k-mooney ack
12:40:03 sean-k-mooney i think form the data that gibi capatured we have all the info we need to proeprly simulate this in unit/fuctional tests
12:45:21 gibi tkajinam: thanks
12:45:47 bauzas tkajinam: thanks !
12:52:55 tkajinam sean-k-mooney, yes
12:53:28 tkajinam sean-k-mooney, one question. do you want me to rebase the whole sev series on top of your change to push all startup checks into the libvirt driver ?
12:53:55 tkajinam sean-k-mooney, the question might be equivalent to whether you'll backport your fix to stable branches.
12:54:21 tkajinam the whole sev-snp series, I mean
12:55:45 sean-k-mooney am either that or put your new check in init_host in the driver and i can fix it in mine
12:55:58 sean-k-mooney but im hoping to backport my fixes so both oders wil work
12:56:56 sean-k-mooney tkajinam: so this function call in driver.init_host in the libvirt driver https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L924-L926
12:57:15 sean-k-mooney is pulling all the instnaces form the db and backfilling the default for the image properties
12:57:44 sean-k-mooney so you could make https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L980-L997 return the list of instances
12:57:50 sean-k-mooney and hten use that ot do your check
12:57:59 sean-k-mooney but it woudl be cleaner ot rebase i think
12:58:30 tkajinam yeah I read your change and I think I now understand how the check should be implemented after that fix.
12:58:31 sean-k-mooney driver.init_host is called before we do the hostname validation and it really shoudl not have been loading the instance form the db like that
12:59:30 tkajinam I agree
13:03:36 sean-k-mooney i guess gibi or bauzas may have a prefernce but without https://github.com/openstack/nova/commit/2714c71d05e8501ddb3a8fc0c36f3406ef974072 those checks in the compute manager for self._validate_pinning_configuration(instances) and self._validate_vtpm_configuration(instances) were lazy loading the image propereis and flavor on every instance for every driver

Earlier   Later