Hello, On Fri, Jan 15, 2021 at 08:32:19PM -0800, Vipin Sharma wrote: > SEV-ES has stronger memory encryption gurantees compared to SEV, apart > from encrypting the application memory it also encrypts register state > among other things. In a single host ASIDs can be distributed between > these two types by BIOS settings. > > Currently, Google Cloud has Confidential VM machines offering using SEV. > ASIDs are not compatible between SEV and SEV-ES, so a VM running on SEV > cannot run on SEV-ES and vice versa > > There are use cases for both types of VMs getting used in future. Can you please elaborate? I skimmed through the amd manual and it seemed to say that SEV-ES ASIDs are superset of SEV but !SEV-ES ASIDs. What's the use case for mixing those two? > > > > > Other ID types can be easily added in the controller in the same way. > > > > > > > > I'm not sure this is necessarily a good thing. > > > > > > This is to just say that when Intel and PowerPC changes are ready it > > > won't be difficult for them to add their controller. > > > > I'm not really enthused about having per-hardware-type control knobs. None > > of other controllers behave that way. Unless it can be abstracted into > > something common, I'm likely to object. > > There was a discussion in Patch v1 and consensus was to have individual > files because it makes kernel implementation extremely simple. > > https://lore.kernel.org/lkml/alpine.DEB.2.23.453.2011131615510.333518@xxxxxxxxxxxxxxxxxxxxxxxxx/#t I'm very reluctant to ack vendor specific interfaces for a few reasons but most importantly because they usually indicate abstraction and/or the underlying feature not being sufficiently developed and they tend to become baggages after a while. So, here are my suggestions: * If there can be a shared abstraction which hopefully makes intuitive sense, that'd be ideal. It doesn't have to be one knob but it shouldn't be something arbitrary to specific vendors. * If we aren't there yet and vendor-specific interface is a must, attach that part to an interface which is already vendor-aware. > This information is not available anywhere else in the system. Only > other way to get this value is to use CPUID instruction (0x8000001F) of > the processor. Which also has disdvantage if sev module in kernel > doesn't use all of the available ASIDs for its work (right now it uses > all) then there will be a mismatch between what user get through their > code and what is actually getting used in the kernel by sev. > > In cgroup v2, I didn't see current files for other cgroups in root > folder that is why I didn't show that file in root folder. > > Will you be fine if I show two files in the root, something like: > > encids.sev.capacity > encids.sev.current > > In non root folder, it will be: > encids.sev.max > encids.sev.current > > I still prefer encids.sev.stat, as it won't repeat same information in > each cgroup but let me know what you think. Yeah, this will be a first and I was mostly wondering about the same number appearing under different files / names on root and !root cgroups. I'm leaning more towards capacity/current but let me think about it a bit more. Thank you. -- tejun
