similar to: SEV, SEV-ES, SEV-SNP

On Wed, Jul 15, 2020 at 11:24:56AM +0200, Peter Zijlstra wrote: > Can we get some more words -- preferably in actual code comments, on > when exactly #VC happens? Sure, will add this as a comment before the actual runtime VC handler. > Because the only thing I remember is that #VC could happen on any memop, > but I also have vague memories of that being a later extention. Currently

On Wed, Jul 15, 2020 at 11:24:56AM +0200, Peter Zijlstra wrote: > Can we get some more words -- preferably in actual code comments, on > when exactly #VC happens? Sure, will add this as a comment before the actual runtime VC handler. > Because the only thing I remember is that #VC could happen on any memop, > but I also have vague memories of that being a later extention. Currently

On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: > I have a somewhat serious question: should we use IST for #VC at all? > As I understand it, Rome and Naples make it mandatory for hypervisors > to intercept #DB, which means that, due to the MOV SS mess, it's sort > of mandatory to use IST for #VC. But Milan fixes the #DB issue, so, > if we're running under

On Tue, Jun 23, 2020 at 01:50:14PM +0200, Peter Zijlstra wrote: > If SNP is the sole reason #VC needs to be IST, then I'd strongly urge > you to only make it IST if/when you try and make SNP happen, not before. It is not the only reason, when ES guests gain debug register support then #VC also needs to be IST, because #DB can be promoted into #VC then, and as #DB is IST for a reason,

On 2/13/20 11:23 PM, Joerg Roedel wrote: > Yes, investigating this is on the list for future optimizations (besides > caching CPUID results). My idea is to use alternatives patching for > this. But the exception handling is needed anyway because #VC > exceptions happen very early already, basically the first thing after > setting up a stack is calling verify_cpu(), which uses CPUID.

On Thu, Jun 04, 2020 at 12:15:02PM +0200, Joerg Roedel wrote: > On Wed, Jun 03, 2020 at 04:07:16PM -0700, Sean Christopherson wrote: > > On Wed, Jun 03, 2020 at 04:23:25PM +0200, Joerg Roedel wrote: > > > User-space can also cause IOIO #VC exceptions, and user-space can be > > > 32-bit legacy code with segments, so es_base has to be taken into > > > account.

On Tue, Apr 28, 2020 at 05:16:52PM +0200, Joerg Roedel wrote: > diff --git a/arch/x86/include/asm/sev-es.h b/arch/x86/include/asm/sev-es.h > index b2cbcd40b52e..e1ed963a57ec 100644 > --- a/arch/x86/include/asm/sev-es.h > +++ b/arch/x86/include/asm/sev-es.h > @@ -74,5 +74,6 @@ static inline u64 lower_bits(u64 val, unsigned int bits) > } > > extern void vc_no_ghcb(void);

On Tue, Apr 28, 2020 at 05:16:52PM +0200, Joerg Roedel wrote: > diff --git a/arch/x86/include/asm/sev-es.h b/arch/x86/include/asm/sev-es.h > index b2cbcd40b52e..e1ed963a57ec 100644 > --- a/arch/x86/include/asm/sev-es.h > +++ b/arch/x86/include/asm/sev-es.h > @@ -74,5 +74,6 @@ static inline u64 lower_bits(u64 val, unsigned int bits) > } > > extern void vc_no_ghcb(void);

On Tue, Feb 11, 2020 at 03:50:08PM +0100, Peter Zijlstra wrote: > Oh gawd; so instead of improving the whole NMI situation, AMD went and > made it worse still ?!? Well, depends on how you want to see it. Under SEV-ES an IRET will not re-open the NMI window, but the guest has to tell the hypervisor explicitly when it is ready to receive new NMIs via the NMI_COMPLETE message. NMIs stay

Hello, I am working on implementing SEV support in OpenStack. There are some questions that came up in the discussion of the spec [0] [0] https://review.openstack.org/#/c/641994/ As far as i understand, the memory for SEV machines need to be pinned so that it doesn't migrate to swap and page migration. ROMS, UEFI pflash and video RAM should be pinned too. Initially we planned to use

On Tue, Feb 11, 2020 at 03:50:08PM +0100, Peter Zijlstra wrote: > Oh gawd; so instead of improving the whole NMI situation, AMD went and > made it worse still ?!? Well, depends on how you want to see it. Under SEV-ES an IRET will not re-open the NMI window, but the guest has to tell the hypervisor explicitly when it is ready to receive new NMIs via the NMI_COMPLETE message. NMIs stay

On Tue, Apr 28, 2020 at 05:16:48PM +0200, Joerg Roedel wrote: > +bool sev_es_active(void) > +{ > + return !!(sev_status & MSR_AMD64_SEV_ES_ENABLED); > +} > +EXPORT_SYMBOL_GPL(sev_es_active); I don't see this being used in modules anywhere in the patchset. Or am I missing something? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

On Sat, Apr 25, 2020 at 1:23 PM Joerg Roedel <joro at 8bytes.org> wrote: > > On Sat, Apr 25, 2020 at 12:47:31PM -0700, Andy Lutomirski wrote: > > I assume the race you mean is: > > > > #VC > > Immediate NMI before IST gets shifted > > #VC > > > > Kaboom. > > > > How are you dealing with this? Ultimately, I think that NMI will need

On Thu, Jun 04, 2020 at 01:54:13PM +0200, Joerg Roedel wrote: > It is not only the trace-point, this would also eliminate exception > handling in case the MSR access triggers a #GP. The "Unhandled MSR > read/write" messages would turn into a "General Protection Fault" > message. But the early ones can trigger a #GP too. And there we can't handle those #GPs.

On Wed, Jun 03, 2020 at 04:23:25PM +0200, Joerg Roedel wrote: > > > + */ > > > + io_bytes = (exit_info_1 >> 4) & 0x7; > > > + ghcb_count = sizeof(ghcb->shared_buffer) / io_bytes; > > > + > > > + op_count = (exit_info_1 & IOIO_REP) ? regs->cx : 1; > > > + exit_info_2 = min(op_count, ghcb_count); > > > +

On Wed, Jun 03, 2020 at 04:23:25PM +0200, Joerg Roedel wrote: > > > + */ > > > + io_bytes = (exit_info_1 >> 4) & 0x7; > > > + ghcb_count = sizeof(ghcb->shared_buffer) / io_bytes; > > > + > > > + op_count = (exit_info_1 & IOIO_REP) ? regs->cx : 1; > > > + exit_info_2 = min(op_count, ghcb_count); > > > +

On Tue, Jun 23, 2020 at 12:51:03PM +0100, Andrew Cooper wrote: > There are cases which are definitely non-recoverable. > > For both ES and SNP, a malicious hypervisor can mess with the guest > physmap to make the the NMI, #VC and #DF stacks all alias. > > For ES, this had better result in the #DF handler deciding that crashing > is the way out, whereas for SNP, this had

On Tue, Jun 23, 2020 at 01:14:43PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 01:11:07PM +0200, Joerg Roedel wrote: > > The v3 patchset implements an unconditional shift of the #VC IST entry > > in the NMI handler, before it can trigger a #VC exception. > > Going by that other thread -- where you said that any memory access can > trigger a #VC, there just

On Tue, Apr 28, 2020 at 05:16:35PM +0200, Joerg Roedel wrote: > From: Tom Lendacky <thomas.lendacky at amd.com> > > Add support for decoding and handling #VC exceptions for IOIO events. > > Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> > [ jroedel at suse.de: Adapted code to #VC handling framework ] > Co-developed-by: Joerg Roedel <jroedel at

On Tue, Apr 28, 2020 at 05:16:35PM +0200, Joerg Roedel wrote: > From: Tom Lendacky <thomas.lendacky at amd.com> > > Add support for decoding and handling #VC exceptions for IOIO events. > > Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> > [ jroedel at suse.de: Adapted code to #VC handling framework ] > Co-developed-by: Joerg Roedel <jroedel at