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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0896C77B76 for ; Fri, 21 Apr 2023 19:24:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D61726B0071; Fri, 21 Apr 2023 15:24:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D124E6B0072; Fri, 21 Apr 2023 15:24:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD91F6B0074; Fri, 21 Apr 2023 15:24:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id AE0316B0071 for ; Fri, 21 Apr 2023 15:24:55 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 77CBF1A0266 for ; Fri, 21 Apr 2023 19:24:55 +0000 (UTC) X-FDA: 80706375750.12.071D8E4 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf26.hostedemail.com (Postfix) with ESMTP id AFA09140014 for ; Fri, 21 Apr 2023 19:24:53 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=Z1mYNDZ6; spf=pass (imf26.hostedemail.com: domain of atishp@rivosinc.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=atishp@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682105093; a=rsa-sha256; cv=none; b=MmcFzZshTUMHgK6mDjC8kEOp1wmwgvC/OuiMHG8LBvB5gSRF0IkocMtxvloj9hYaW3ETi2 LaMmuF3fHtjqc7EZeNuCSUuWSis3B7RIH63ghWsswEXebjaEPtNJPlV2Y+GiXFekf5HX/p 1Z04UPHTODV5gBO7+HJcZu7esnRmnfs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=Z1mYNDZ6; spf=pass (imf26.hostedemail.com: domain of atishp@rivosinc.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=atishp@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682105093; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lvkLA+a8YoW/wuOsjaIxJzuPVSb1YjjMK/JpWWUYlMo=; b=6spC6iLarh0zfPWUVqQOWZCwGYk2BgqUklw870LGQvz8vFn7pcIeIqnJVAgyPcfExOUMOq eiLHMChnRHiTg9UGwKoVhe6FV3uESYR88q0FnVhL0yjzLPwDuiMboghDR1cAyLwmmJTEgm KC+JdyjA9f7PakGD+/9pv4oCgPHmuPg= Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1a92369761cso22202535ad.3 for ; Fri, 21 Apr 2023 12:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1682105092; x=1684697092; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lvkLA+a8YoW/wuOsjaIxJzuPVSb1YjjMK/JpWWUYlMo=; b=Z1mYNDZ6AkudtVnrT3n5V/eEIts8OddUDSW9KLn74LxIddwBxxMBvHvXimDOcCpD64 X6WHStiU+II2uxk73igF03YyRe+mqwSuW6H9Qtdv7u/DWvtDubpnzfk1YriCRr9za8v5 XC2S0BuPZrz2o6+CZXODj0TbYeG2KwCM2cVe6oSpp9pVUDXxGg9olTtkau7Q+5+NsYc4 cPFBjLGEPHFWzzeOrmDbwFXicua/PB03j/rs7FblIcXdCvm1JDi0Tcgqxr22anUmw5R3 tGRsDEZo6/EsKO19A+OOzPNIS7W+AHqe2QZk6VRckV7ELyCwNp6MWsNbX2FhgYUyMfrE CxsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682105092; x=1684697092; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lvkLA+a8YoW/wuOsjaIxJzuPVSb1YjjMK/JpWWUYlMo=; b=dseIgtkwhqMXxtlhREfbYNMrHnMPvYMu2ci6enbwUW8n4K8JAo1jj0M0oNwgF+Dy+l oeNVSucso/IN+rU4w5CSUNB5MZ1ZBjAiBHMMhHAGcReo2Wbk0NeWI0BHR+qBHJ1yiTHP 2jkH97S+KsXVTVklbJJ6FFOwyQnxyN6DL9HMe1KVPb74klK+JpxHdthYQkzLs7Didoou veMZJuauTo//KS/RTPTPfAO4fBuM6AIb1q7PBVOCyuJx7jfQbTYDD4mwcsmO8xNSKgXF WDtVRu5ZtG4QT6H4e1GhLtS++4EJ/aBLYl5igbsRlr+xu4Ah1r7gYvamRK3C8PtzR2ag hEzQ== X-Gm-Message-State: AAQBX9eHMcvsJP+VQ7qtOQ/QNT2yCmC5HWgGKkALqXv1Vw6KylQgLqBV VO5WAQsk/lmySHV6VNp1KsFMd0W9UzCFmDhmFLQOmA== X-Google-Smtp-Source: AKy350bWDl0o884sMlNpmr/NR+NvkEPHrIR9Z4zX48mWh2RO0zn4bHfGQxbBytUzrO9XtFhCP8cwpF/T0JLyArYTY9E= X-Received: by 2002:a17:903:22c8:b0:1a6:c12d:9036 with SMTP id y8-20020a17090322c800b001a6c12d9036mr7907063plg.33.1682105092516; Fri, 21 Apr 2023 12:24:52 -0700 (PDT) MIME-Version: 1.0 References: <20230419221716.3603068-1-atishp@rivosinc.com> <20230419221716.3603068-46-atishp@rivosinc.com> <69ba1760-a079-fd8f-b079-fcb01e3eedec@intel.com> In-Reply-To: <69ba1760-a079-fd8f-b079-fcb01e3eedec@intel.com> From: Atish Kumar Patra Date: Sat, 22 Apr 2023 00:54:41 +0530 Message-ID: Subject: Re: [RFC 45/48] RISC-V: ioremap: Implement for arch specific ioremap hooks To: Dave Hansen Cc: linux-kernel@vger.kernel.org, Rajnesh Kanwal , Alexandre Ghiti , Andrew Jones , Andrew Morton , Anup Patel , Atish Patra , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Suzuki K Poulose , Will Deacon , Marc Zyngier , Sean Christopherson , linux-coco@lists.linux.dev, Dylan Reid , abrestic@rivosinc.com, Samuel Ortiz , Christoph Hellwig , Conor Dooley , Greg Kroah-Hartman , Guo Ren , Heiko Stuebner , Jiri Slaby , kvm-riscv@lists.infradead.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, Mayuresh Chitale , Palmer Dabbelt , Paolo Bonzini , Paul Walmsley , Uladzislau Rezki Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: AFA09140014 X-Rspamd-Server: rspam01 X-Stat-Signature: 8jrr1b4cuop49nqd91dafkxdooskocxt X-HE-Tag: 1682105093-285829 X-HE-Meta: U2FsdGVkX19nSNkmIMONAMuwwYcLbSr4P9X1lI4ezvLsdBCQZ3i1nglowj+uKbD35T2fgEvBFBP/xS6k/IHHA7Toy5K60SrXXPLesQbnDauHjky9McWooRhx6H38hKOZ44f7o0/G6gZC8FyAbBp+KcAzLogBgJe8jUv+sbANr2orb5zT7BBl2ITs3jRItYaoDDeJUSbjsJekmrf0KY9q/5JzIQf46OUdiQwD72HKcmGzHjo6EBAAY5djKhYhm7F1NdCwtijpgzP6RYUDAnuKYBuabeOpMEf9JJjH4eG24qBuSjFJ1rFsSfqDwG5qXOxdWIz9yHIKCdBZbXnubkvRDKR//YN/mR6gB3LwXCcDj+fzzEePIGekmQaTMoTIoQ+yUnSLDuzggxKagAfFyoBBADW3XdjmJcrK2V3Lt2BJ9ebd9Fo6LKFOIbwe9D2x5Ov0SEWxnpZ2dIjVO4GBQS0KIVzt4iPHFIYrBjzOax/xJaA3C+KWzsDHUU64GOAWOK7NCRnWPZRwCOAfdquVzaEwyV2pgBmHvV57rARCebVS/P81MFgv+/uSVCqKA4PCgcsGoI3gW/cjjx7V4SQazEB9uDqavoOZ/1n/PrLPgab6Yxn880F1nw2azVqpUCg6ISGH5BryIAT3blOozKevjKXSCnf8KpzyBmb3I9b7/32A8X7mSdANZmrlH+Fld5Ebjn4LAdUtIW7fJZPi3KMPfNUJMfcr2YwIKmxJpSyeVKmZvHtwtUdFdYshtFs7ZXxnaUEHAqZL8M2/mahWJCdfecpxo9R99XCeunAIzkUV2ofcNhuZ7eGOBJhWUJeioTKkkL9Ro9XOqEbUoP0OVZZpwgrtnFDwY25AUj+GlwI0JqCP+U0sfYpjxPEDX/4AM99PBaJrQEEYlWt86iZGkZ9ADKYKwc7nguL/aW6i8pN1jWBWBt902PLhAcjObpcNDwtUuCVMOcImXSab4PkLBRVd74c nE0XFBzR Kn9EOaKUoSKXLXu4kqVp2LPf1mtu7/zKeDAEOHd/S1P8xDkM1qSqRnrZv2NxX8IhOMMe9pk8/Y75fVPhstejvu9Pamlfm1FEYF0N4f4bi1y4Q+UoQMbiAFVEF9JYEJTymXdWlzxkjyEkWtkF2KMrPxbVPbV9psO25VyE9+mdA+t76ed4WN5GgkfDUniaQutdnWrbNDTULQfOUV/TYSDiBHGisxj/WYetr1p8fgF3+H0DTgCwU6YSqJ9ZkjuLbbr6iMZ7nQIDtHt2mflGQV2arxLTJj+4/k+CQC5xsibh0A96ssimaAojBoR4t9XePxpasrGWVow0aBjOdHOwc3EmMEFwJOYXtdDjUtCu/ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Apr 21, 2023 at 3:46=E2=80=AFAM Dave Hansen = wrote: > > On 4/19/23 15:17, Atish Patra wrote: > > The guests running in CoVE must notify the host about its mmio regions > > so that host can enable mmio emulation. > > This one doesn't make a lot of sense to me. > > The guest and host must agree about the guest's physical layout up > front. In general, the host gets to dictate that layout. It tells the > guest, up front, what is present in the guest physical address space. > That is passed through DT/ACPI (which will be measured) to the guest. > This callback appears to say to the host: > > Hey, I (the guest) am treating this guest physical area as MMIO. > > But the host and guest have to agree _somewhere_ what the MMIO is used > for, not just that it is being used as MMIO. > Yes. The TSM (TEE Security Manager) which is equivalent to TDX also needs to be aware of the MMIO regions so that it can forward the faults accordingly. Most of the MMIO is emulated in the host (userspace or kernel emulation if present). The host is outside the trust boundary of the guest. Thus, guest needs to make sure the host only emulates the designated MMIO region. Otherwise, it opens an attack surface from a malicious host. All other confidential computing solutions also depend on guest initiated MMIO as well. AFAIK, the TDX & SEV relies on #VE like exceptions to invoke that while this patch is similar to what pkvm does. This approach lets the enlightened guest control which MMIO regions it wants the host to emulate. It can be a subset of the region's host provided the layout. The guest device filtering solution is based on this idea as well [1]. [1] https://lore.kernel.org/all/20210930010511.3387967-1-sathyanarayanan.ku= ppuswamy@linux.intel.com/ >