Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-07-06
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 :)
16:45:09 sean-k-mooney right
16:45:13 sean-k-mooney i also dont think we need that
16:45:17 sean-k-mooney but that a seprate issue
16:45:27 sean-k-mooney i want to make sure we are reporting the trait
16:45:36 sean-k-mooney when a host supprot it or not for schduling
16:45:49 gibi as far as I understand we need the /proc/cpuinfo because we would like to have a startup check
16:45:58 sean-k-mooney and we shoudl do that based on what libvirt reports
16:46:11 gibi sean-k-mooney: even if libvirt reports it wrongly?
16:46:15 sean-k-mooney yes
16:46:20 gibi I don't like that
16:46:22 sean-k-mooney i dont think nova shoudl be secondguessing libvirt
16:46:43 sean-k-mooney also we have not fully confirmed libvirt reports it incorrectly
16:46:49 sean-k-mooney it repoce 2 diffent things
16:46:54 sean-k-mooney it reporst the sev capastiy
16:47:04 sean-k-mooney and seperate it reprot what modes can be used for sev to lauch a vm
16:47:38 sean-k-mooney there wre 3 modes of sev sofar
16:47:45 sean-k-mooney sev, sev-es and sev-snp
16:47:56 sean-k-mooney in the lauch security section it only has sev and sev-snp
16:48:00 sean-k-mooney not sev-es
16:48:13 sean-k-mooney so i think libvirt is correctly reporting that sev-es cant be used
16:48:31 tkajinam that's basically because they use same enum (sev) for sev and sev-es
16:48:41 tkajinam sev-snp is there because they introduced a different enum (for different scheme)
16:49:26 sean-k-mooney i see
16:49:34 tkajinam I agree it's not quite ideal and doesn't show full items we want to know
16:49:37 sean-k-mooney can we defer this and come back to it
16:49:44 sean-k-mooney i.e. next week
16:49:51 sean-k-mooney i really dont like this
16:50:00 tkajinam I at least add large TODO there and consider how we can improve libvirt to get rid of that hack
16:50:19 sean-k-mooney to be clear this hack is enouch to punt the feature until libvirt is fixed in my view
16:50:28 sean-k-mooney im trying to come aroudn to a diffent approch
16:50:36 tkajinam but if people can spend some time reviewing it and give some more feedback about this topic that would be appreciated
16:50:46 sean-k-mooney but i have been toold by nova cores to go fix libvirt for similar issue multipel times
16:51:07 gibi sean-k-mooney: I'm totally not OK punting a working feature just because we need self contained workaround for a libvirt / amd complication
16:51:17 gibi I'm OK to wait a week and reasses
16:51:29 bauzas tkajinam: as said I'll definitely review your series
16:51:44 tkajinam bauzas, thanks
16:52:14 bauzas and yeah we can revisit that next week
16:52:19 Uggla guys I think that's the conclusion for today.
16:52:31 tkajinam we also might need some discussion about how we implement the startup check but that would be less prioritized. the discussion can be found in the series so I appreciate any thoughts about it, too.
16:52:32 bauzas (at least personnally I'll appreciate it to have more context :D )
16:52:35 tkajinam yup
16:53:37 Uggla thanks tkajinam, antia and gibi
16:53:59 sean-k-mooney tkajinam: i htink we need my change to add the new driver fuction or you need to do it in the libvirt drivers init host but sure we can disucss in gerrit
16:54:16 Uggla #topic Bug scrubbing
16:54:22 Uggla #info up to 91 (-3)
16:54:27 Uggla #link https://etherpad.opendev.org/p/nova-bug-triage-roster
16:54:33 Uggla #link https://truc.uggla.fr/ to follow the trend.
16:54:37 tkajinam sean-k-mooney, thanks. yeah I just opened your change and will check it soon.
16:54:44 Uggla Next meeting (this week): [public] Upstream bug triage. Wednesday, July 8th · 15:30 – 16:00 UTC. Video call link: meet.google.com/zjr-rxus-hzj
16:54:52 Uggla #topic Open discussion
16:55:01 Uggla Uggla: PTO next 3 weeks. gibi will host the meeting next week then bauzas will host the next 2 ones.
16:55:17 gibi yepp
16:55:20 Uggla something you'd like to quickly share in the lastest 5 mn
16:56:19 gibi -
16:56:41 Uggla if not I guess we are done for today.
16:56:48 Uggla Thanks for joining this meeting. Have a nice day/evening.
16:56:55 gibi thanks folks
16:56:55 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-07-06-16.00.log.html
16:56:55 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-07-06-16.00.txt
16:56:55 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-07-06-16.00.html
16:56:55 opendevmeet Meeting ended Mon Jul 6 16:56:55 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:56:55 Uggla #endmeeting
16:57:00 tkajinam thanks !
16:57:05 antia thanks :)

Earlier   Later