Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-10
11:22:55 sean-k-mooney no i dont have sev hardware
11:23:20 gmann aspiers: within scope of QA ecosystem not Tempest ecosystem. Tempest is just a tool under QA :)
11:23:24 artom aspiers, yeah, we're not saying "don't do it", we're saying "don't propose patches for it to Tempest"
11:23:46 aspiers artom: OK, it sounded like the former before :)
11:24:02 aspiers gmann: the white box tempest plugin isn't in the tempest ecosystem? ;-)
11:24:10 sean-k-mooney aspiers: whitebox and the intel nfv test repo use tempest as a framework
11:24:16 sean-k-mooney to do this type of testing
11:24:30 sean-k-mooney but its not in tempest as its out of scope fo tempest
11:24:47 sean-k-mooney but a whitebox style tempest plugin for sev would be fine
11:24:53 sean-k-mooney or add it to whitebox
11:25:04 artom sean-k-mooney, unrelated, but we had some discussion around saving the new NUMA topology in https://review.opendev.org/#/c/634606/75/nova/compute/manager.py@7223 - and in func tests at least, that instance.refresh() isn't necessary (yes, the tests check the InstanceNUMATopology)
11:25:21 gmann aspiers: It will be QA ecosystem. it can be done via tempest plugin or separate testing framework like extreme-testing( which never got progress ). but it will be separate project under QA with separate team.
11:25:34 artom sean-k-mooney, I'll try to get to the office later this morning, to see what's up with my machine, would you have the bandwidth to play around with that in the meantime in your env?
11:26:16 sean-k-mooney artom: since this is aparently our highest priority i can make time
11:26:23 sean-k-mooney what exactly do you want me to test
11:26:35 sean-k-mooney remove the instace.refresh
11:26:46 artom sean-k-mooney, I did that already in the latest patchset
11:27:02 artom Making sure that the new instance NUMA topology is saved in the DB
11:27:08 sean-k-mooney and check both the db and virsh to confrim that the state is updated correctly?
11:27:13 sean-k-mooney ok
11:27:29 sean-k-mooney ya ill do that now
11:27:41 artom Thank you (for the ∞'s time)
11:27:43 artom :)
11:28:26 aspiers sean-k-mooney: BTW lscpu on the guest does not mention sev at all
11:28:50 sean-k-mooney as i said before i have exposed the servers im using for testing via port forwarding so if you continue to have issue then you can ssh into them
11:29:12 sean-k-mooney aspiers: is there anything in dmidecode/dmesg to indicate sev
11:29:30 sean-k-mooney i though the guest had to set bit 48 to 1 to enable the encryption
11:29:36 sean-k-mooney for pointers
11:30:32 aspiers sean-k-mooney: http://paste.openstack.org/show/774681/
11:30:36 aspiers doesn't even look right
11:31:45 artom sean-k-mooney, IIRC when I tried connecting last time I couldn't - but yeah, what's the connection info again?
11:32:09 sean-k-mooney https://events.linuxfoundation.org/wp-content/uploads/2017/12/Extending-Secure-Encrypted-Virtualization-with-SEV-ES-Thomas-Lendacky-AMD.pdf looking at slide 12 we might be able to check it via the gurest msr
11:32:58 sean-k-mooney artom: i have two routter my isp one and my ubiquity one. my isp router firwall was blocking it so i truned it off and it started working
11:33:14 aspiers sean-k-mooney: I will ask the experts
11:34:42 artom sean-k-mooney, sure, but I still don't have the IP/FQDN in my bash history for some reason
11:35:06 sean-k-mooney artom: ya i know im looking it up in mine/my router config
11:41:27 kashyap aspiers: Randomly chiming in, but there is an MSR for SEV: https://www.kernel.org/doc/html/latest/x86/amd-memory-encryption.html
11:41:40 kashyap aspiers: And it's reported via `cpuid`
11:41:47 kashyap "Support for SME and SEV can be determined through the CPUID instruction. The CPUID function 0x8000001f reports information related to SME:"
11:41:59 kashyap And:
11:42:05 kashyap "If SEV is supported, MSR 0xc0010131 (MSR_AMD64_SEV) can be used to determine if SEV is active: [...]"
11:42:16 aspiers Yeah, I've already used that in the past
11:42:49 kashyap Ah, then disregard me.
11:42:57 aspiers No, the reminder is appreciated
11:43:39 kashyap aspiers: Your goal is to check if the instance (in the upstream CI) booted has indeed with SEV, yeah?
11:43:44 aspiers right
11:44:02 aspiers I guess the JeOS image will need to include cpuid
11:44:32 kashyap Isn't the JeOS (Just Enough OS, I presume) CirrOS in this case?
11:44:55 aspiers It's whatever tempest is configured with
11:45:07 kashyap (Nod)
11:47:13 sean-k-mooney aspiers: has one of the upstream ci provered provided you with a lable that will run on SEV hardware
11:47:41 sean-k-mooney aspiers: because 90% of the upstream ci cloud are proably runing intel x86_64
11:47:57 sean-k-mooney although rackspace did run power for a while
11:48:19 aspiers sean-k-mooney: SUSE has our own SEV boxes which can run 3rd party CI
11:48:42 sean-k-mooney ah so its for the suse thrid party ci not for upstream
11:48:55 aspiers well if upstream has SEV hardware then great, but I was not expecting that any time soon
11:49:10 sean-k-mooney aspiers: i dont think it currely does
11:49:17 sean-k-mooney or at least not in a way you can target
11:49:49 sean-k-mooney im sure some of the clould proably have at least a small amd eypc inventory if for nothing else but there own internal validation
11:50:50 aspiers yeah
12:00:03 donnyd sean-k-mooney: have the numa jobs been running?
12:02:57 donnyd I saw last night it was having some inbound ssh timeout issues.
12:04:09 sean-k-mooney i have not checked this morning but i think clarkb kicked off a job around 4/5 am so ill see if that passed
12:04:51 sean-k-mooney donnyd: so that one failed at 04:54
12:05:01 sean-k-mooney donnyd: was that after your l3 agent restart
12:05:22 donnyd i didn't restart till well after you were talking about it on infra last night
12:06:31 sean-k-mooney donnyd: ya looking at the infra scroll back clarkb kicked that off after you did the restart
12:06:35 openstackgerrit Chris Dent proposed openstack/os-resource-classes master: Update api-ref link to canonical location https://review.opendev.org/681235
12:06:46 donnyd oh yea i see
12:07:31 donnyd It really just makes no sense though
12:07:42 donnyd all the rest of the labels seem to work without issue
12:07:57 donnyd mostly without issue... not anymore than any other provider at least
12:09:54 openstackgerrit Chris Dent proposed openstack/os-traits master: Update README to be a bit more clear https://review.opendev.org/681237
12:09:57 donnyd So the old label we have setup for numa, does that still work?
12:10:07 donnyd I haven't set it back on my end
12:12:44 openstackgerrit Balazs Gibizer proposed openstack/nova master: Shrink the race window in confirm resize func test https://review.opendev.org/681238
12:25:02 kashyap aspiers: Is there a way to detect from _inside_ the guest that it has indeed booted with SEV?
12:25:20 kashyap aspiers: (From the host, we can use the CPUID bit or other ways)
12:26:51 kashyap aspiers: Meanwhile, I learnt that if SEV isn't provided by the host, an SEV-enabled kernel should fail to boot.
12:27:38 openstackgerrit Alexandra Settle proposed openstack/nova master: Fixing broken links https://review.opendev.org/681206
12:29:31 openstackgerrit Chris Dent proposed openstack/os-traits master: Update README to be a bit more clear https://review.opendev.org/681237
12:30:13 gibi efried, aspiers: Is there anything I can do regarding the SEV series?
12:30:15 stephenfin aspiers: Random question: why can we not add the iommu attribute for all those device types?
12:30:30 stephenfin gibi: I'm reviewing the last patch now. Think you've already hit it though
12:30:36 stephenfin by which I mean the first one
12:30:41 stephenfin since the other two are +2
12:30:49 stephenfin +W
12:30:51 gibi stephenfin: cool. Yeah I tried to find somebody how can look at the first
12:31:05 gibi but then it is in good hands now
12:33:40 kashyap aspiers: Also, when you're about, see my response to your comment: https://review.opendev.org/#/c/348394/10
12:34:33 kashyap aspiers: If you can confirm that /usr/share/qemu/ovmf-x86_64-suse-code.bin is indeed the binary built with Secure Boot, then we can fix it
12:34:36 luyao Hi, everyone, I have a question, when an instance is in rebuild, how many allocations will it have? Both new and old ?
12:43:00 brinzhang efried: Could you please review this patch https://review.opendev.org/#/c/681151/, it changes the novalient version to 15.1.0, needed by https://review.opendev.org/#/c/673725/
12:44:12 stephenfin aspiers: Is that follow-up for https://review.opendev.org/#/c/666616/ around yet?
12:47:35 gibi stephenfin: I did not find the followup either so I guess it isn't
12:58:43 openstackgerrit Stephen Finucane proposed openstack/nova master: Apply SEV-specific guest config when SEV is required https://review.opendev.org/644565
12:58:44 openstackgerrit Stephen Finucane proposed openstack/nova master: Reject live migration and suspend on SEV guests https://review.opendev.org/680158
12:58:44 openstackgerrit Stephen Finucane proposed openstack/nova master: Enable booting of libvirt guests with AMD SEV memory encryption https://review.opendev.org/666616
12:58:45 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start reporting PCPU inventory to placement https://review.opendev.org/671793
12:58:45 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: '_get_(v|p)cpu_total' to '_get_(v|p)cpu_available' https://review.opendev.org/672693

Earlier   Later