On 9/24/20 2:21 PM, Sean Christopherson wrote:
On Tue, Sep 22, 2020 at 02:14:04PM -0700, Vipin Sharma wrote:
On Mon, Sep 21, 2020 at 06:48:38PM -0700, Sean Christopherson wrote:
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.
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.
I read about the TDX and its use of the KeyID for encrypting VMs. TDX
has two kinds of KeyIDs private and shared.
To clarify, "shared" KeyIDs are simply legacy MKTME KeyIDs. This is relevant
because those KeyIDs can be used without TDX or KVM in the picture.
On AMD platform there are two types of ASIDs for encryption.
1. SEV ASID - Normal runtime guest memory encryption.
2. SEV-ES ASID - Extends SEV ASID by adding register state encryption with
integrity.
Both types of ASIDs have their own maximum value which is provisioned in
the firmware
Ugh, I missed that detail in the SEV-ES RFC. Does SNP add another ASID type,
or does it reuse SEV-ES ASIDs? If it does add another type, is that trend
expected to continue, i.e. will SEV end up with SEV, SEV-ES, SEV-ES-SNP,
SEV-ES-SNP-X, SEV-ES-SNP-X-Y, etc...?
SEV-SNP and SEV-ES share the same ASID range.
Thanks,
Tom
So, we are talking about 4 different types of resources:
1. AMD SEV ASID (implemented in this patch as sev.* files in SEV cgroup)
2. AMD SEV-ES ASID (in future, adding files like sev_es.*)
3. Intel TDX private KeyID
4. Intel TDX shared KeyID
TDX private KeyID is similar to SEV and SEV-ES ASID. I think coming up
with the same name which can be used by both platforms will not be easy,
and extensible with the future enhancements. This will get even more
difficult if Arm also comes up with something similar but with different
nuances.
Honest question, what's easier for userspace/orchestration layers? Having an
abstract but common name, or conrete but different names? My gut reaction is
to provide a common interface, but I can see how that could do more harm than
good, e.g. some amount of hardware capabilitiy discovery is possible with
concrete names. And I'm guessing there's already a fair amount of vendor
specific knowledge bleeding into userspace for these features...
And if SNP is adding another ASID namespace, trying to abstract the types is
probably a lost cause.
From a code perspective, I doubt it will matter all that much, e.g. it should
be easy enough to provide helpers for exposing a new asid/key type.
I like the idea of the KVM cgroup and when it is mounted it will have
different files based on the hardware platform.
I don't think a KVM cgroup is the correct approach, e.g. there are potential
use cases for "legacy" MKTME without KVM. Maybe something like Encryption
Keys cgroup?
1. KVM cgroup on AMD will have:
sev.max & sev.current.
sev_es.max & sev_es.current.
2. KVM cgroup mounted on Intel:
tdx_private_keys.max
tdx_shared_keys.max
The KVM cgroup can be used to have control files which are generic (no
use case in my mind right now) and hardware platform specific files
also.
My "generic KVM cgroup" suggestion was probably a pretty bad suggestion.
Except for ASIDs/KeyIDs, KVM itself doesn't manage any constrained resources,
e.g. memory, logical CPUs, time slices, etc... are all generic resources that
are consumed by KVM but managed elsewhere. We definitely don't want to change
that, nor do I think we want to do anything, such as creating a KVM cgroup,
that would imply that having KVM manage resources is a good idea.
