From: Tom Lendacky <thomas.lendacky@amd.com> To: Peter Gonda <pgonda@google.com> Cc: Sean Christopherson <sean.j.christopherson@intel.com>, Vipin Sharma <vipinsh@google.com>, Paolo Bonzini <pbonzini@redhat.com>, tj@kernel.org, lizefan@huawei.com, Joerg Roedel <joro@8bytes.org>, corbet@lwn.net, "Singh, Brijesh" <brijesh.singh@amd.com>, "Grimm, Jon" <jon.grimm@amd.com>, eric.vantassell@amd.com, Matt Gingell <gingell@google.com>, David Rientjes <rientjes@google.com>, kvm list <kvm@vger.kernel.org>, x86@kernel.org, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC Patch 0/2] KVM: SVM: Cgroup support for SVM SEV ASIDs Date: Thu, 1 Oct 2020 17:44:08 -0500 [thread overview] Message-ID: <cc3e88df-0c6e-2a8c-80aa-4dc3f0d8cea9@amd.com> (raw) In-Reply-To: <CAMkAt6oX+18cZy_t3hm0zo-sLmTGeGs5H9YAWvj7WBU7_uwU5Q@mail.gmail.com> On 10/1/20 1:08 PM, Peter Gonda wrote: > On Thu, Sep 24, 2020 at 1:55 PM Tom Lendacky <thomas.lendacky@amd.com> wrote: >> >> 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. > > Where is this documented? From the SEV-SNP FW ABI Spec 0.8 "The > firmware checks that ASID is an encryption capable ASID. If not, the > firmware returns INVALID_ASID." that doesn't seem clear that an SEV-ES > ASID is required. Should this document be more clear? I let the owner of the spec know and it will be updated. Thanks, Tom >
WARNING: multiple messages have this Message-ID (diff)
From: Tom Lendacky <thomas.lendacky-5C7GfCeVMHo@public.gmane.org> To: Peter Gonda <pgonda-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Cc: Sean Christopherson <sean.j.christopherson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Vipin Sharma <vipinsh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Paolo Bonzini <pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>, corbet-T1hC0tSOHrs@public.gmane.org, "Singh, Brijesh" <brijesh.singh-5C7GfCeVMHo@public.gmane.org>, "Grimm, Jon" <jon.grimm-5C7GfCeVMHo@public.gmane.org>, eric.vantassell-5C7GfCeVMHo@public.gmane.org, Matt Gingell <gingell-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, kvm list <kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [RFC Patch 0/2] KVM: SVM: Cgroup support for SVM SEV ASIDs Date: Thu, 1 Oct 2020 17:44:08 -0500 [thread overview] Message-ID: <cc3e88df-0c6e-2a8c-80aa-4dc3f0d8cea9@amd.com> (raw) In-Reply-To: <CAMkAt6oX+18cZy_t3hm0zo-sLmTGeGs5H9YAWvj7WBU7_uwU5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On 10/1/20 1:08 PM, Peter Gonda wrote: > On Thu, Sep 24, 2020 at 1:55 PM Tom Lendacky <thomas.lendacky-5C7GfCeVMHo@public.gmane.org> wrote: >> >> 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. > > Where is this documented? From the SEV-SNP FW ABI Spec 0.8 "The > firmware checks that ASID is an encryption capable ASID. If not, the > firmware returns INVALID_ASID." that doesn't seem clear that an SEV-ES > ASID is required. Should this document be more clear? I let the owner of the spec know and it will be updated. Thanks, Tom >
next prev parent reply other threads:[~2020-10-01 22:44 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-22 0:40 [RFC Patch 0/2] KVM: SVM: Cgroup support for SVM SEV ASIDs Vipin Sharma 2020-09-22 0:40 ` [RFC Patch 1/2] KVM: SVM: Create SEV cgroup controller Vipin Sharma 2020-09-22 1:04 ` Randy Dunlap 2020-09-22 1:04 ` Randy Dunlap 2020-09-22 1:22 ` Sean Christopherson 2020-09-22 16:05 ` Vipin Sharma 2020-09-22 16:05 ` Vipin Sharma 2020-11-03 16:39 ` James Bottomley 2020-11-03 18:10 ` Sean Christopherson 2020-11-03 22:43 ` James Bottomley 2020-09-22 7:54 ` kernel test robot 2020-09-22 0:40 ` [RFC Patch 2/2] KVM: SVM: SEV cgroup controller documentation Vipin Sharma 2020-09-22 0:40 ` Vipin Sharma 2020-09-22 1:48 ` [RFC Patch 0/2] KVM: SVM: Cgroup support for SVM SEV ASIDs Sean Christopherson 2020-09-22 21:14 ` Vipin Sharma 2020-09-22 21:14 ` Vipin Sharma [not found] ` <20200924192116.GC9649@linux.intel.com> 2020-09-24 19:55 ` Tom Lendacky 2020-09-24 19:55 ` Tom Lendacky 2020-09-25 22:22 ` Vipin Sharma 2020-10-02 20:48 ` Vipin Sharma 2020-11-03 2:06 ` Sean Christopherson 2020-11-14 0:26 ` David Rientjes 2020-11-24 19:16 ` Sean Christopherson 2020-11-24 19:49 ` Vipin Sharma 2020-11-24 19:49 ` Vipin Sharma 2020-11-24 20:18 ` David Rientjes 2020-11-24 21:08 ` Vipin Sharma 2020-11-24 21:27 ` Sean Christopherson 2020-11-24 21:27 ` Sean Christopherson 2020-11-24 22:21 ` Vipin Sharma 2020-11-24 23:18 ` Sean Christopherson 2020-11-27 18:01 ` Christian Borntraeger 2020-11-27 18:01 ` Christian Borntraeger 2020-10-01 18:08 ` Peter Gonda 2020-10-01 22:44 ` Tom Lendacky [this message] 2020-10-01 22:44 ` Tom Lendacky 2020-09-23 12:47 ` Paolo Bonzini 2020-09-23 12:47 ` Paolo Bonzini 2020-09-23 12:47 ` Paolo Bonzini 2020-09-28 9:12 ` Janosch Frank 2020-09-28 9:12 ` Janosch Frank 2020-09-28 9:21 ` Christian Borntraeger 2020-09-28 9:21 ` Christian Borntraeger
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=cc3e88df-0c6e-2a8c-80aa-4dc3f0d8cea9@amd.com \ --to=thomas.lendacky@amd.com \ --cc=brijesh.singh@amd.com \ --cc=cgroups@vger.kernel.org \ --cc=corbet@lwn.net \ --cc=eric.vantassell@amd.com \ --cc=gingell@google.com \ --cc=jon.grimm@amd.com \ --cc=joro@8bytes.org \ --cc=kvm@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lizefan@huawei.com \ --cc=pbonzini@redhat.com \ --cc=pgonda@google.com \ --cc=rientjes@google.com \ --cc=sean.j.christopherson@intel.com \ --cc=tj@kernel.org \ --cc=vipinsh@google.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.