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 6953FC433ED for ; Tue, 18 May 2021 16:10:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3E544611EE for ; Tue, 18 May 2021 16:10:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350455AbhERQLz (ORCPT ); Tue, 18 May 2021 12:11:55 -0400 Received: from mga02.intel.com ([134.134.136.20]:60211 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344604AbhERQLx (ORCPT ); Tue, 18 May 2021 12:11:53 -0400 IronPort-SDR: X0R0zvuAgcLq2gyOMf7j2M9x686tlTFxrv9qrsrgiiQ8j3Csx6K3j+F7uO985hSRsiwalgxB3d fE+2MP4AkRsA== X-IronPort-AV: E=McAfee;i="6200,9189,9988"; a="187876019" X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="187876019" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 09:10:06 -0700 IronPort-SDR: kmGiyr+Bq3vHPT6wHBn+AK/L1D6QMQn/asQRKwONY3Li/Sl1/4ReMc4omdVFtJ+40/KWOWpPdy jTUpmnSGaJfA== X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="439506337" 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 09:10:05 -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> <43e583a3-ee2b-52d8-5275-e26a6609c126@linux.intel.com> <94dc5a5a-8c51-8624-5810-e6278783789c@intel.com> From: Andi Kleen Message-ID: Date: Tue, 18 May 2021 09:10:04 -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: <94dc5a5a-8c51-8624-5810-e6278783789c@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 >>>> 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. > I've heard exactly the opposite from the TDX team in the past. What I > remember was a claim that one can not just leverage the MMIO macros as a > single point to avoid MMIO. I remember being told that not all code in > the kernel that does MMIO uses these macros. APIC MMIO's were called > out as a place that does not use the MMIO macros. Yes x86 APIC has its own macros, but we don't use the MMIO based APIC, only X2APIC in TDX. I'm not aware of any other places that would do MMIO without using the standard io.h macros, although it might happen in theory on x86 (but would likely break on some other architectures) -Andi