From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C03DC433E1 for ; Tue, 23 Jun 2020 14:49:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2236B20720 for ; Tue, 23 Jun 2020 14:49:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732848AbgFWOtp (ORCPT ); Tue, 23 Jun 2020 10:49:45 -0400 Received: from mx2.suse.de ([195.135.220.15]:38190 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732738AbgFWOtp (ORCPT ); Tue, 23 Jun 2020 10:49:45 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 16C4CADAA; Tue, 23 Jun 2020 14:49:43 +0000 (UTC) Date: Tue, 23 Jun 2020 16:49:40 +0200 From: Joerg Roedel To: Peter Zijlstra Cc: Andy Lutomirski , Joerg Roedel , Dave Hansen , Tom Lendacky , Mike Stunes , Dan Williams , Dave Hansen , "H. Peter Anvin" , Juergen Gross , Jiri Slaby , Kees Cook , kvm list , LKML , Thomas Hellstrom , Linux Virtualization , X86 ML , Sean Christopherson , Andrew Cooper Subject: Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace) Message-ID: <20200623144940.GE14101@suse.de> References: <20200623094519.GF31822@suse.de> <20200623104559.GA4817@hirez.programming.kicks-ass.net> <20200623111107.GG31822@suse.de> <20200623111443.GC4817@hirez.programming.kicks-ass.net> <20200623114324.GA14101@suse.de> <20200623115014.GE4817@hirez.programming.kicks-ass.net> <20200623121237.GC14101@suse.de> <20200623130322.GH4817@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200623130322.GH4817@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, Jun 23, 2020 at 03:03:22PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 02:12:37PM +0200, Joerg Roedel wrote: > > 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, #VC needs to be too. > > Didn't I read somewhere that that is only so for Rome/Naples but not for > the later chips (Milan) which have #DB pass-through? Probably, not sure which chips will get debug register virtualization under SEV-ES. But even when it is supported, the HV can (and sometimes will) intercept #DB, which then causes it to be promoted to #VC. > We're talking about the 3rd case where the only reason things 'work' is > because we'll have to panic(): > > - #MC Okay, #MC is special and can only be handled on a best-effort basis, as #MC could happen anytime, also while already executing the #MC handler. > - #DB with BUS LOCK DEBUG EXCEPTION If I understand the problem correctly, this can be solved by moving off the IST stack to the current task stack in the #DB handler, like I plan to do for #VC, no? > - #VC SNP This has to panic for other reasons that can't be worked around. It boils down to detecting that the HV is doing something fishy and bail out to avoid further harm (like in the #MC handler). Regards, Joerg