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 7C4C2C433ED for ; Tue, 18 May 2021 17:21:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4DB13610CD for ; Tue, 18 May 2021 17:21:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351106AbhERRXL (ORCPT ); Tue, 18 May 2021 13:23:11 -0400 Received: from mga01.intel.com ([192.55.52.88]:22867 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238824AbhERRXI (ORCPT ); Tue, 18 May 2021 13:23:08 -0400 IronPort-SDR: hhbr7QDyxRSUtVET4037vgE5GX23PVAJuCPruRfdCe8DDKAL8c4cixigUMF8avajokt9aCWFOc rkvQo7zYalag== X-IronPort-AV: E=McAfee;i="6200,9189,9988"; a="221827225" X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="221827225" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 10:21:49 -0700 IronPort-SDR: OQkeYakY61neRLBdlSgOP9qxaCynB3oR8FeACAQ+qSN+y0MEYLDURNqhtuQ1Ri1ZY/vf0Y8OS0 n3NdGxrv7bcw== X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="439532769" Received: from akleen-mobl1.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 10:21:48 -0700 Subject: Re: [RFC v2-fix 1/1] x86/tdx: Handle in-kernel MMIO To: Sean Christopherson Cc: Dave Hansen , Kuppuswamy Sathyanarayanan , Peter Zijlstra , Andy Lutomirski , Tony Luck , Kirill Shutemov , Kuppuswamy Sathyanarayanan , Dan Williams , Raj Ashok , 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> From: Andi Kleen Message-ID: <8fb0e52c-ed0a-2185-585a-27007c27ed56@linux.intel.com> Date: Tue, 18 May 2021 10:21:47 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > The extra bytes for .altinstructions is very different than the extra bytes for > the code itself. The .altinstructions section is freed after init, so yes it > bloats the kernel size a bit, but the runtime footprint is unaffected by the > patching metadata. > > IIRC, patching read/write{b,w,l,q}() can be done with 3 bytes of .text overhead. > > The other option to explore is to hook/patch IO_COND(), which can be done with > neglible overhead because the helpers that use IO_COND() are not inlined. In a > TDX guest, redirecting IO_COND() to a paravirt helper would likely cover the > majority of IO/MMIO since virtio-pci exclusively uses the IO_COND() wrappers. > And if there are TDX VMMs that want to deploy virtio-mmio, hooking > drivers/virtio/virtio_mmio.c directly would be a viable option. Yes but what's the point of all that? Even if it's only 3 bytes we still have a lot of MMIO all over the kernel which never needs it. And I don't even see what TDX (or SEV which already does the decoding and has been merged) would get out of it. We handle all the #VEs just fine. And the instruction handling code is fairly straight forward too. Besides instruction decoding works fine for all the existing hypervisors. All we really want to do is to do the same thing as KVM would do. -Andi