| Message ID | 20210721142015.1401-12-joro@8bytes.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/sev: KEXEC/KDUMP support for SEV-ES guests | expand |
On Wed, Jul 21, 2021, Joerg Roedel wrote: > From: Joerg Roedel <jroedel@suse.de> > > Handle CLFLUSH instruction to MMIO memory in the #VC handler. The ^ |- emulated > instruction is ignored by the handler, as the Hypervisor is > responsible for cache management of emulated MMIO memory. > > Signed-off-by: Joerg Roedel <jroedel@suse.de> > --- > arch/x86/kernel/sev-shared.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c > index a7a0793c4f98..682fa202444f 100644 > --- a/arch/x86/kernel/sev-shared.c > +++ b/arch/x86/kernel/sev-shared.c > @@ -632,6 +632,15 @@ static enum es_result vc_handle_mmio_twobyte_ops(struct ghcb *ghcb, > long *reg_data; > > switch (insn->opcode.bytes[1]) { > + /* CLFLUSH */ > + case 0xae: > + /* > + * Ignore CLFLUSHes - those go to emulated MMIO anyway and the > + * hypervisor is responsible for cache management. This wording can be misread as "the hypervisor is responsible for _all_ cache management". Maybe just: /* * Ignore CLFLUSHes - the hyperivsor is responsible for cache * management of emulated MMIO. */ Side topic, out of curisoity, what's mapping/accessing emulated MMIO as non-UC? > + */ > + ret = ES_OK; > + break; > + > /* MMIO Read w/ zero-extension */ > case 0xb6: > bytes = 1; > -- > 2.31.1 >
Hi Sean, On Fri, Jul 30, 2021 at 10:42:30PM +0000, Sean Christopherson wrote: > On Wed, Jul 21, 2021, Joerg Roedel wrote: > This wording can be misread as "the hypervisor is responsible for _all_ cache > management". Maybe just: > > /* > * Ignore CLFLUSHes - the hyperivsor is responsible for cache > * management of emulated MMIO. > */ Right, will update the comment, thanks. > Side topic, out of curisoity, what's mapping/accessing emulated MMIO as non-UC? The CLFLUSHes happen when the kexec'ed kernel maps the VGA framebuffer as unencrypted. Initially it is mapped encrypted and before re-mapping the kernel flushes the range from the caches. I have not investigated why this doesn't happen on the first boot, though. Regards, Joerg
diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c index a7a0793c4f98..682fa202444f 100644 --- a/arch/x86/kernel/sev-shared.c +++ b/arch/x86/kernel/sev-shared.c @@ -632,6 +632,15 @@ static enum es_result vc_handle_mmio_twobyte_ops(struct ghcb *ghcb, long *reg_data; switch (insn->opcode.bytes[1]) { + /* CLFLUSH */ + case 0xae: + /* + * Ignore CLFLUSHes - those go to emulated MMIO anyway and the + * hypervisor is responsible for cache management. + */ + ret = ES_OK; + break; + /* MMIO Read w/ zero-extension */ case 0xb6: bytes = 1;