On 28.09.20 11:12, Janosch Frank wrote: > On 9/23/20 2:47 PM, Paolo Bonzini wrote: >> On 22/09/20 03:48, Sean Christopherson wrote: >>> This should be genericized to not be SEV specific. TDX has a similar >>> scarcity issue in the form of key IDs, which IIUC are analogous to SEV ASIDs >>> (gave myself a quick crash course on SEV ASIDs). Functionally, I doubt it >>> would change anything, I think it'd just be a bunch of renaming. The hardest >>> part would probably be figuring out a name :-). >>> >>> Another idea would be to go even more generic and implement a KVM cgroup >>> that accounts the number of VMs of a particular type, e.g. legacy, SEV, >>> SEV-ES?, and TDX. That has potential future problems though as it falls >>> apart if hardware every supports 1:MANY VMs:KEYS, or if there is a need to >>> account keys outside of KVM, e.g. if MKTME for non-KVM cases ever sees the >>> light of day. >> >> Or also MANY:1 (we are thinking of having multiple VMs share the same >> SEV ASID). >> >> It might even be the same on s390 and PPC, in which case we probably >> want to implement this in virt/kvm. Paul, Janosch, do you think this >> would make sense for you? The original commit message is below. >> >> Paolo >> >>> On Mon, Sep 21, 2020 at 05:40:22PM -0700, Vipin Sharma wrote: >>>> Hello, >>>> >>>> This patch series adds a new SEV controller for tracking and limiting >>>> the usage of SEV ASIDs on the AMD SVM platform. >>>> >>>> SEV ASIDs are used in creating encrypted VM and lightweight sandboxes >>>> but this resource is in very limited quantity on a host. >>>> >>>> This limited quantity creates issues like SEV ASID starvation and >>>> unoptimized scheduling in the cloud infrastructure. >>>> >>>> SEV controller provides SEV ASID tracking and resource control >>>> mechanisms. >> > > On s390 we currently support a few million protected guests per LPAR so > guest IDs are not exactly scarce. However having accounting for them > might add some value nevertheless, especially when having large amount > of protected containers. > > @Christian: Any thoughts on this? Yes, maybe it is a good idea to limit containers to only have a sane number of secure guests, so that a malicious pod cannot consume all IDs by calling CREATE_VM and KVM_PV_ENABLE million times or so.
