Messages in this thread | | | Subject | Re: [PATCH] x86/sev-es: Do not unroll string I/O for SEV-ES guests | From | Tom Lendacky <> | Date | Mon, 1 Feb 2021 12:34:31 -0600 |
| |
On 2/1/21 12:26 PM, Tom Lendacky wrote: > From: Tom Lendacky <thomas.lendacky@amd.com> > > Under the GHCB specification, SEV-ES guests can support string I/O. The > current #VC handler contains this support, so remove the need to unroll > kernel string I/O operations. This will reduce the number of #VC > exceptions generated as well as the number VMEXITS for the guest. > > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> > --- > arch/x86/mm/mem_encrypt.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c > index c79e5736ab2b..d55ea77e1ca8 100644 > --- a/arch/x86/mm/mem_encrypt.c > +++ b/arch/x86/mm/mem_encrypt.c > @@ -474,9 +474,10 @@ void __init mem_encrypt_init(void) > swiotlb_update_mem_attributes(); > > /* > - * With SEV, we need to unroll the rep string I/O instructions. > + * With SEV, we need to unroll the rep string I/O instructions, > + * but SEV-ES supports them through the #VC handler. > */ > - if (sev_active()) > + if (sev_active() && !sev_es_active()) > static_branch_enable(&sev_enable_key);
This brings up a question. The name implies that this is a general SEV related key. However, it's currently only used for the string I/O operations. If further usage of this key is added in the future, then this would probably need to be split into two keys, the sev_enable_key and an sev_unroll_io_key.
Is it worth documenting that in the comment? Or should the key be renamed now?
Thanks, Tom
> > print_mem_encrypt_feature_info(); > > base-commit: a7e0bdf1b07ea6169930ec42b0bdb17e1c1e3bb0 >
| |