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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 D429CC433ED for ; Tue, 18 May 2021 15:57:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A47BF60725 for ; Tue, 18 May 2021 15:57:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350508AbhERP6x (ORCPT ); Tue, 18 May 2021 11:58:53 -0400 Received: from mga12.intel.com ([192.55.52.136]:59187 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350480AbhERP6v (ORCPT ); Tue, 18 May 2021 11:58:51 -0400 IronPort-SDR: GvKliayCrsKSygqPg55lDbUbeUxabKMuz5/1EiA75JS+Azcr7I2ebYihEyrKdztxva1nYcVJ89 gAMLtYx+VBDQ== X-IronPort-AV: E=McAfee;i="6200,9189,9988"; a="180349931" X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="180349931" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 08:56:35 -0700 IronPort-SDR: z0g/9luv2LW0Bv8ya4CBBWhVf/O0tqqr6okTgFhwzmWzVguUBYB2Ep7t7ZLaMTP1i933egEkiU Q4Px3ZljA5Xw== X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="439500398" Received: from msaber-mobl.amr.corp.intel.com (HELO [10.209.65.183]) ([10.209.65.183]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 08:56:34 -0700 Subject: Re: [RFC v2-fix 1/1] x86/tdx: Handle in-kernel MMIO To: Dave Hansen , Kuppuswamy Sathyanarayanan , Peter Zijlstra , Andy Lutomirski Cc: Tony Luck , Kirill Shutemov , Kuppuswamy Sathyanarayanan , Dan Williams , Raj Ashok , Sean Christopherson , linux-kernel@vger.kernel.org References: <3e9a26c3-8eee-88f5-f8e2-8a2dd2c028ea@intel.com> <20210518004807.258503-1-sathyanarayanan.kuppuswamy@linux.intel.com> <36cd2665-6d8b-9c0b-eec1-25152dcca2a3@intel.com> From: Andi Kleen Message-ID: <43e583a3-ee2b-52d8-5275-e26a6609c126@linux.intel.com> Date: Tue, 18 May 2021 08:56:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <36cd2665-6d8b-9c0b-eec1-25152dcca2a3@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/18/2021 8:00 AM, Dave Hansen wrote: > On 5/17/21 5:48 PM, Kuppuswamy Sathyanarayanan wrote: >> From: "Kirill A. Shutemov" >> >> In traditional VMs, MMIO tends to be implemented by giving a >> guest access to a mapping which will cause a VMEXIT on access. >> That's not possible in TDX guest. > Why is it not possible? For once the TDX module doesn't support uncached mappings (IgnorePAT is always 1) > >> For now we only handle a subset of instructions that the kernel >> uses for MMIO operations. User-space access triggers SIGBUS. > How do you know which instructions the kernel uses? They're all in MMIO macros. > How do you know > that the compiler won't change them? The macros try hard to prevent that because it would likely break real MMIO too. Besides it works for others, like AMD-SEV today and of course all the hypervisors that do the same. > That sounds like something objective we can measure. Does this cost 1 > byte of extra text per readl/writel? 10? 100? Alternatives are at least a pointer, but also the extra alternative code. It's definitely more than 10, I would guess 40+ > > I thought there were more than a few ways that userspace could get > access to MMIO mappings. Yes and they will all fault in TDX guests. >> + if (user_mode(regs)) { >> + pr_err("Unexpected user-mode MMIO access.\n"); >> + force_sig_fault(SIGBUS, BUS_ADRERR, (void __user *) ve->gla); > extra space ^ > > Is a non-ratelimited pr_err() appropriate here? I guess there shouldn't > be any MMIO passthrough to userspace on these systems. Yes rate limiting makes sense.