Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1070471ybb; Fri, 20 Mar 2020 12:49:31 -0700 (PDT) X-Google-Smtp-Source: ADFU+vun7z8MyV3m6k5+X0gc0qslEsLpCwEWIvvZR3AW/MDRm7xOKURJaSfwnIOtH9tkDppkoOs7 X-Received: by 2002:a05:6830:6:: with SMTP id c6mr7992702otp.84.1584733771384; Fri, 20 Mar 2020 12:49:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584733771; cv=none; d=google.com; s=arc-20160816; b=ycBthWgji+S5Tdq40KVl03dq1vcw5xRLIo0nwcv1HnVs6yffK77LGnVNyId/DUiG1f 5BdOxvY7uaLI7CIL0Kn40RxG/Zta5uZNqR7vgAdgXtleKfeKA0QKaZyE64vxb7e7BL47 Su/XwRo817gpicgvml6cl3VFrtX+J8XQfDLZiN9W0lCi2eOuHKSlehquXGaPz2uGIs4Q /yDSI7U309nhJGYBcT5XCEt/CN5cAOIVc/4brU13zRNE/5i4yGSaDjF5qcYC+sYqp1pB 9Zz2E4RMPSDmHiRS2pMhBr7XkT4p/+3VjbcD9rWSJ0/WIn89bW0Eg3+EZMGl96p9fkDh tQ3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=iMOWmKY9xNW/yLOUeHZ5Gpf40fweQPjDsAJUWYSHsZk=; b=YN5dtCsL+ujc+NLhcRZNZd5ZiNAt2c4J89BjwGZ/Oq9NUipNzW4k8SCB/yHdUJ7o6a PP5N9nFsDTc3ggq/GrxJNc1hQgXO7i1E/l8ZgkFmqyoX/Eh8TM4lqaiCVE+MpHOIpgzq UUvQBHtfi0w/fwV4nCYTyuET1BMXFw34d/ZtejzjyS44R7kcuX5/qVxJT+2klkj+P54/ iAmcfuHX1ZHa5uy3x72x0z5jgVwrGhCNpvRcKPnsGyUWG86WwiVY4q3vvG/zRPrw5O5h cpyEIbvfpyq7jOlTBDQ4PjYDsheNsG2n4WshYbAja3Z+wajlp+mCKmXksFJ3g40wCZPb qC1g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h9si3533164oti.155.2020.03.20.12.49.17; Fri, 20 Mar 2020 12:49:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726951AbgCTTsx (ORCPT + 99 others); Fri, 20 Mar 2020 15:48:53 -0400 Received: from 8bytes.org ([81.169.241.247]:54648 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726666AbgCTTsw (ORCPT ); Fri, 20 Mar 2020 15:48:52 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id 4F2324CA; Fri, 20 Mar 2020 20:48:51 +0100 (CET) Date: Fri, 20 Mar 2020 20:48:49 +0100 From: Joerg Roedel To: Andy Lutomirski Cc: Joerg Roedel , X86 ML , "H. Peter Anvin" , Dave Hansen , Peter Zijlstra , Thomas Hellstrom , Jiri Slaby , Dan Williams , Tom Lendacky , Juergen Gross , Kees Cook , LKML , kvm list , Linux Virtualization Subject: Re: [PATCH 70/70] x86/sev-es: Add NMI state tracking Message-ID: <20200320194849.GJ5122@8bytes.org> References: <20200319091407.1481-1-joro@8bytes.org> <20200319091407.1481-71-joro@8bytes.org> <20200319160749.GC5122@8bytes.org> <20200319192654.GD611@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 19, 2020 at 02:27:49PM -0700, Andy Lutomirski wrote: > AIUI the shift-ist stuff is because we aren't very good about the way > that we handle tracing right now, and that can cause a limited degree > of recursion. #DB uses IST for historical reasons that don't > necessarily make sense. Right now, we need it for only one reason: > the MOV SS issue. IIRC this isn't actually triggerable without > debugging enabled -- MOV SS with no breakpoint but TF on doesn't seem > to malfunction quite as badly. I had a look at the shift_ist stuff today and it looks like a good solution to the #VC nesting problem when it is turned into a #VC handler. The devil is in the details, of course, as 3 or 4 stacks for the #VC handler (per cpu) should only be allocated when actually running in an SEV-ES guest. Let's see how this works out in practice. Regards, Joerg