Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1B85C38142 for ; Tue, 31 Jan 2023 15:53:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233242AbjAaPxq (ORCPT ); Tue, 31 Jan 2023 10:53:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231671AbjAaPxo (ORCPT ); Tue, 31 Jan 2023 10:53:44 -0500 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 035D417154 for ; Tue, 31 Jan 2023 07:53:44 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id l4-20020a17090a850400b0023013402671so2816541pjn.5 for ; Tue, 31 Jan 2023 07:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8BDBGIr020TIEN48KHoXszHSY7JH31zE2b6DhwjqkpU=; b=i0jigBhmeRjaAtvW2bVUaQPHSOXnmtp6KW5DRBVBoMs9M95X0qKfuKWydeztA7qQ9A +PqS3GEUcHUGwBfRKP3Zuz3rfg+thRbu4mVBTTUBXhpE9TUVjx24IUQzns0scPtIXuMT ctgHAVgpKcpJ7by5c58aOPLIilAVT9b9knMJz8fqgIO1SLTBHQ7f8kLcc5QbQOpKEC9Q qJFBMGogqJC3mGYSXcXl1IxvbUJfJ6CHTl5z6jH2in9+Gl1URvuhstI5fQt6nPIRDK0n wBCdfAIvDjt2WfX6v2ee8EjsAimhl2K90y6zivnNcHzOd78Q7m/lJtG+6nBvZHCHKZmh iFHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8BDBGIr020TIEN48KHoXszHSY7JH31zE2b6DhwjqkpU=; b=Ori/HJITzC4lKM74OiR/s7o1etYYcreke/zCRXKTNwPOjJmf0CFokLW0f9dLrFtv4m wjtQ0wRIIPKgiWT6sy+pj9/jWz7EhtZ2ZWjBz8WbJlQYVHOXSM1R1+pwtizkLH2vQyNY hMIAkDeVFITMvBec7MTO6QgKtA/YFh1K+VzyhsgOBfVCOjP4U63ucy+XnRJOZz/L/F+v OQNoqZETNUSuRWc6Hf0X4GQRdrRtFaW+wsg00uscpLWnte/kbWSiBoB4tqpqp0w8vvzD n9oWxAn2OeGmiKDnbUThoUYRiBEUY9oQbupv8Df02MFGv2RoMJIabLhGhQqFPYoZkjeP L1QA== X-Gm-Message-State: AO0yUKXFGTWAF658jHAblYDJwFbbGfHLgJ033pGtd9QbxF9nEEzM3MZM J+WOhTGe5SEqr4CIj6fo5aaBxg== X-Google-Smtp-Source: AK7set86Spbju15zAbisK2mmq3j8WKEdenghpKFRQltXbuwmg9z/EBPdC24x5DEU09pf9f5AKKLB0w== X-Received: by 2002:a17:902:b686:b0:191:4367:7fde with SMTP id c6-20020a170902b68600b0019143677fdemr1307314pls.0.1675180423267; Tue, 31 Jan 2023 07:53:43 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id x17-20020a170902ea9100b00196768692e0sm5338448plb.86.2023.01.31.07.53.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Jan 2023 07:53:42 -0800 (PST) Date: Tue, 31 Jan 2023 15:53:39 +0000 From: Sean Christopherson To: Joerg Roedel Cc: "H. Peter Anvin" , Alexey Kardashevskiy , Peter Zijlstra , kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Jiri Kosina , Ingo Molnar , Dave Hansen , Borislav Petkov , Tom Lendacky Subject: Re: [Question PATCH kernel] x86/amd/sev/nmi+vc: Fix stack handling (why is this happening?) Message-ID: References: <20230127035616.508966-1-aik@amd.com> <3bb3e080-caee-8bc8-7de9-f44969f16e75@amd.com> <38C572D7-E637-48C2-A57A-E62D44FF19BB@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 31, 2023, Joerg Roedel wrote: > On Mon, Jan 30, 2023 at 09:30:38AM -0800, H. Peter Anvin wrote: > > It's somewhat odd to me that reading %dr7 is volatile, but %dr6 is > > not... %dr6 is the status register! > > The reason is that on SEV-ES only accesses to DR7 will cause #VC > exceptions, DR0-DR6 are not intercepted. I don't think that is technically true. A _well-behaved_ hypervisor will not intercept DR0-DR6 accesses for SEV-ES guests, but AFAICT nothing in the SEV-ES architecture enforces that behavior.