From: Tom Lendacky <thomas.lendacky@amd.com> To: Tejun Heo <tj@kernel.org> Cc: Vipin Sharma <vipinsh@google.com>, brijesh.singh@amd.com, jon.grimm@amd.com, eric.vantassell@amd.com, pbonzini@redhat.com, seanjc@google.com, lizefan@huawei.com, hannes@cmpxchg.org, frankja@linux.ibm.com, borntraeger@de.ibm.com, corbet@lwn.net, joro@8bytes.org, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, gingell@google.com, rientjes@google.com, dionnaglaze@google.com, kvm@vger.kernel.org, x86@kernel.org, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller Date: Thu, 21 Jan 2021 17:12:43 -0600 [thread overview] Message-ID: <d11e58ec-4a8f-5b31-063a-b6b45d4ccdc5@amd.com> (raw) In-Reply-To: <YAmj4Q2J9htW2Fe8@mtj.duckdns.org> On 1/21/21 9:55 AM, Tejun Heo wrote: > Hello, > > On Thu, Jan 21, 2021 at 08:55:07AM -0600, Tom Lendacky wrote: >> The hardware will allow any SEV capable ASID to be run as SEV-ES, however, >> the SEV firmware will not allow the activation of an SEV-ES VM to be >> assigned to an ASID greater than or equal to the SEV minimum ASID value. The >> reason for the latter is to prevent an !SEV-ES ASID starting out as an >> SEV-ES guest and then disabling the SEV-ES VMCB bit that is used by VMRUN. >> This would result in the downgrading of the security of the VM without the >> VM realizing it. >> >> As a result, you have a range of ASIDs that can only run SEV-ES VMs and a >> range of ASIDs that can only run SEV VMs. > > I see. That makes sense. What's the downside of SEV-ES compared to SEV w/o > ES? Are there noticeable performance / feature penalties or is the split > mostly for backward compatibility? SEV-ES is an incremental enhancement of SEV where the register state of the guest is protected/encrypted. As with a lot of performance questions, the answer is ...it depends. With SEV-ES, there is additional overhead associated with a world switch (VMRUN/VMEXIT) to restore and save additional register state. Also, exit events are now divided up into automatic exits (AE) and non-automatic exits (NAE). NAE events result in a new #VC exception being generated where the guest is then required to use the VMGEXIT instruction to communicate only the state necessary to perform the operation. A CPUID instruction is a good example, where a shared page is used to communicate required state to the hypervisor to perform the CPUID emulation, which then returns the results back through the shared page to the guest. So it all depends on how often the workload in question performs operations that result in a VMEXIT of the vCPU, etc. Thanks, Tom > > Thanks. >
WARNING: multiple messages have this Message-ID (diff)
From: Tom Lendacky <thomas.lendacky-5C7GfCeVMHo@public.gmane.org> To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Vipin Sharma <vipinsh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, brijesh.singh-5C7GfCeVMHo@public.gmane.org, jon.grimm-5C7GfCeVMHo@public.gmane.org, eric.vantassell-5C7GfCeVMHo@public.gmane.org, pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, seanjc-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org, frankja-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org, borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org, corbet-T1hC0tSOHrs@public.gmane.org, joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org, vkuznets-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, wanpengli-1Nz4purKYjRBDgjK7y7TUQ@public.gmane.org, jmattson-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org, hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org, gingell-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, dionnaglaze-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, 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: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller Date: Thu, 21 Jan 2021 17:12:43 -0600 [thread overview] Message-ID: <d11e58ec-4a8f-5b31-063a-b6b45d4ccdc5@amd.com> (raw) In-Reply-To: <YAmj4Q2J9htW2Fe8-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org> On 1/21/21 9:55 AM, Tejun Heo wrote: > Hello, > > On Thu, Jan 21, 2021 at 08:55:07AM -0600, Tom Lendacky wrote: >> The hardware will allow any SEV capable ASID to be run as SEV-ES, however, >> the SEV firmware will not allow the activation of an SEV-ES VM to be >> assigned to an ASID greater than or equal to the SEV minimum ASID value. The >> reason for the latter is to prevent an !SEV-ES ASID starting out as an >> SEV-ES guest and then disabling the SEV-ES VMCB bit that is used by VMRUN. >> This would result in the downgrading of the security of the VM without the >> VM realizing it. >> >> As a result, you have a range of ASIDs that can only run SEV-ES VMs and a >> range of ASIDs that can only run SEV VMs. > > I see. That makes sense. What's the downside of SEV-ES compared to SEV w/o > ES? Are there noticeable performance / feature penalties or is the split > mostly for backward compatibility? SEV-ES is an incremental enhancement of SEV where the register state of the guest is protected/encrypted. As with a lot of performance questions, the answer is ...it depends. With SEV-ES, there is additional overhead associated with a world switch (VMRUN/VMEXIT) to restore and save additional register state. Also, exit events are now divided up into automatic exits (AE) and non-automatic exits (NAE). NAE events result in a new #VC exception being generated where the guest is then required to use the VMGEXIT instruction to communicate only the state necessary to perform the operation. A CPUID instruction is a good example, where a shared page is used to communicate required state to the hypervisor to perform the CPUID emulation, which then returns the results back through the shared page to the guest. So it all depends on how often the workload in question performs operations that result in a VMEXIT of the vCPU, etc. Thanks, Tom > > Thanks. >
next prev parent reply other threads:[~2021-01-21 23:16 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-08 1:28 [Patch v4 0/2] cgroup: KVM: New Encryption IDs cgroup controller Vipin Sharma 2021-01-08 1:28 ` [Patch v4 1/2] cgroup: svm: Add Encryption ID controller Vipin Sharma 2021-01-08 1:28 ` Vipin Sharma 2021-01-13 15:19 ` Brijesh Singh 2021-01-15 20:59 ` Tejun Heo 2021-01-15 22:18 ` Vipin Sharma 2021-01-16 3:43 ` Tejun Heo 2021-01-16 3:43 ` Tejun Heo 2021-01-16 4:32 ` Vipin Sharma 2021-01-19 15:51 ` Tejun Heo 2021-01-20 7:13 ` Vipin Sharma 2021-01-20 7:13 ` Vipin Sharma 2021-01-20 16:40 ` Tejun Heo 2021-01-20 23:18 ` Vipin Sharma 2021-01-20 23:32 ` Tejun Heo 2021-01-22 0:09 ` Vipin Sharma 2021-01-21 14:55 ` Tom Lendacky 2021-01-21 14:55 ` Tom Lendacky 2021-01-21 15:55 ` Tejun Heo 2021-01-21 15:55 ` Tejun Heo 2021-01-21 23:12 ` Tom Lendacky [this message] 2021-01-21 23:12 ` Tom Lendacky 2021-01-22 1:25 ` Sean Christopherson 2021-01-26 20:49 ` David Rientjes 2021-01-26 20:49 ` David Rientjes 2021-01-26 22:01 ` Tejun Heo 2021-01-26 22:02 ` Tejun Heo 2021-01-27 1:11 ` Vipin Sharma 2021-01-27 1:11 ` Vipin Sharma 2021-01-27 14:10 ` Tejun Heo 2021-01-27 14:10 ` Tejun Heo 2021-01-08 1:28 ` [Patch v4 2/2] cgroup: svm: Encryption IDs cgroup documentation Vipin Sharma 2021-01-15 21:00 ` Tejun Heo 2021-01-15 21:41 ` Vipin Sharma
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=d11e58ec-4a8f-5b31-063a-b6b45d4ccdc5@amd.com \ --to=thomas.lendacky@amd.com \ --cc=borntraeger@de.ibm.com \ --cc=bp@alien8.de \ --cc=brijesh.singh@amd.com \ --cc=cgroups@vger.kernel.org \ --cc=corbet@lwn.net \ --cc=dionnaglaze@google.com \ --cc=eric.vantassell@amd.com \ --cc=frankja@linux.ibm.com \ --cc=gingell@google.com \ --cc=hannes@cmpxchg.org \ --cc=hpa@zytor.com \ --cc=jmattson@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=mingo@redhat.com \ --cc=pbonzini@redhat.com \ --cc=rientjes@google.com \ --cc=seanjc@google.com \ --cc=tglx@linutronix.de \ --cc=tj@kernel.org \ --cc=vipinsh@google.com \ --cc=vkuznets@redhat.com \ --cc=wanpengli@tencent.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.