Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3689419ybt; Tue, 23 Jun 2020 08:27:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJytW/IL+PQj9okDJKiKu3QefBNQ1BA6iXOqHypgk+++v8iZIU7imiJwLQRE25gptT7Wp1wW X-Received: by 2002:a17:906:3958:: with SMTP id g24mr5988833eje.26.1592926053027; Tue, 23 Jun 2020 08:27:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592926053; cv=none; d=google.com; s=arc-20160816; b=tPj7ZMNADs1IIsuz1lZyqrPExWNXFeL/qs9pFYEUYs0ANv4jq2hpKEoYxDGu9s22GT 6BVEzkEIfoQe/YlMeCXe7JJbEU/8vbxgdY+2h1Kc6VJHdqVpvz2qcQ3rZ5J20SocoX/z 5J6kh97xVQgLPnUxa6+6/12iY2KlufoPfTyaMA5RLL4kvbOPXO1+hmvY1JhlsNvSgZkc i70whe0W+Jh5wfQ/nvjZ6OM00OFHbloBKZ+e/hY/W/Gi3RuzxL6pyjUMjoc/dR+Hz8Lf GgASo1tzuMsozmaTgYE8mbIIUKG3V6dhWjGaYZi88k1k99bWfODfmXhZFgSc1cG16w2J kxyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:ironport-sdr; bh=u3/q2Cf4kj7VFU35NFU317iJ0ZUKDjkGKSyECXcY/6I=; b=dGjea9+cYzC18B1UIgJUu8dL529sE3OIzVCiSV7vygyfnB7eutq6UtgiRZyhyagARU p+pyGp345YKhWtPTg/eUyHkaKVV73qhkuvRIb2HKmLN3tmUXrDKxhis4UrK7IbSA1yl4 Xh3PxkkKVFNjUa/+vhEjBOtZ31QpYmlA2Hs8ifTH+yn+MywJR2Wqi62mR3CmUb75Jb2g wyQqFHHuxj8xw9KT/bgfdUb6Uk4TU9Em6d60ckCOhDkUf6w6tWmLCodckVBa+yk50S9E h6DYQOxAncuCWhcpr3CHQDnI0JMpqyXrKYeglWdsSrrN4q1TJMls2R9U0SLxzwhYYOEI +4Zg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=citrix.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t5si3842887ejf.433.2020.06.23.08.27.10; Tue, 23 Jun 2020 08:27:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=citrix.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732950AbgFWPXE (ORCPT + 99 others); Tue, 23 Jun 2020 11:23:04 -0400 Received: from esa5.hc3370-68.iphmx.com ([216.71.155.168]:4829 "EHLO esa5.hc3370-68.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732781AbgFWPXE (ORCPT ); Tue, 23 Jun 2020 11:23:04 -0400 Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /GrFiUnpMH0W1AmH16iOP4fF+hxzWdtD9D+GISmoRYqR9NUtqwq7oNSKz4sucvE9pe0J4q44B7 YPhx3w0bbMe7At7SPDagk+W+pBlnB3922l+qjz6SB7+59/ApAY01JpymxYxQB/94hJVnwwx0hu mFWsCVB1OyWETH6EOQgYMgbq3BvnqklFn/9U3YmTb/P+RlHggHk+LCKhL2ufV+TQIExUPEF/c/ iBObNjUKWYetodeXq+AyoWV8QwqwHww4DnX12xwYBQL5sOXqBlQ7a5064JbCHOcBXl3kQZ+uQp tKU= X-SBRS: 2.7 X-MesageID: 20952771 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,271,1589256000"; d="scan'208";a="20952771" Subject: Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace) To: Peter Zijlstra , Joerg Roedel 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 References: <20200425202316.GL21900@8bytes.org> <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> From: Andrew Cooper Message-ID: <9e3f9b2a-505e-dfd7-c936-461227b4033e@citrix.com> Date: Tue, 23 Jun 2020 16:22:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200623130322.GH4817@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/06/2020 14:03, 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? I don't know about hardware timelines, but some future part can now opt in to having debug registers as part of the encrypted state, and swapped by VMExit, which would make debug facilities generally usable, and supposedly safe to the #DB infinite loop issues, at which point the hypervisor need not intercept #DB for safety reasons. Its worth nothing that on current parts, the hypervisor can set up debug facilities on behalf of the guest (or behind its back) as the DR state is unencrypted, but that attempting to intercept #DB will redirect to #VC inside the guest and cause fun. (Also spare a thought for 32bit kernels which have to cope with userspace singlestepping the SYSENTER path with every #DB turning into #VC.) >> Besides that, I am not a fan of delegating problems I already see coming >> to future-Joerg and future-Peter, but if at all possible deal with them >> now and be safe later. > Well, we could just say no :-) At some point in the very near future > this house of cards is going to implode. What currently exists is a picture of a house of cards in front of something which has fallen down. > Did someone forget to pass the 'ISTs are *EVIL*' memo to the hardware > folks? How come we're getting more and more of them? I have tried to get this point across.  Then again - its far easier for the software folk in the same company as the hardware folk to make this point. > (/me puts fingers > in ears and goes la-la-la-la in anticipation of Andrew mentioning CET) I wasn't going to bring it up, but seeing as you have - while there are prohibitively-complicating issues preventing it from working on native, I don't see any point even considering it for the mess which is #VC, or the even bigger mess which is #HV. ~Andrew