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 3F08BC6FD18 for ; Tue, 25 Apr 2023 08:00:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 619E96B0071; Tue, 25 Apr 2023 04:00:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C94C6B0074; Tue, 25 Apr 2023 04:00:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 490A86B0075; Tue, 25 Apr 2023 04:00:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3712D6B0071 for ; Tue, 25 Apr 2023 04:00:22 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C287E1C653D for ; Tue, 25 Apr 2023 08:00:21 +0000 (UTC) X-FDA: 80719165842.22.EC9A689 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf15.hostedemail.com (Postfix) with ESMTP id AF107A0013 for ; Tue, 25 Apr 2023 08:00:19 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=EOkcITT5; spf=pass (imf15.hostedemail.com: domain of atishp@rivosinc.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=atishp@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682409619; a=rsa-sha256; cv=none; b=U/XSySCTs2Rfp+iXc7Ugina7AwSoOmCuSwAGT9QFKRnEtRPY6cs4rUsb4KG8/0i/6IAyOA /9IQU8Nbbx9WidHgma7LiaTF9NA0ZahoobAKsNJrYZGLaf9wwB+bbSEJAow4F42PdS0GvY RSndY2n5S0a8OIqJ/pWIqlQNSjZrizM= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=EOkcITT5; spf=pass (imf15.hostedemail.com: domain of atishp@rivosinc.com designates 209.85.167.53 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=1682409619; 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=wJcVKVJA3HgnW7bSvVOddaHKG/ERA+dvV0Lub2llU+Q=; b=eDgJY9NRix2tn3b9gDc2uNZbHZgpRN/BakId00vvkITAVJlBX6ILUpoSCcCivTwkletNuZ wBYLBqJAgVwzzrunpnUQ3Rp/BAZG3hC2dZLRU1Z6Cek0WR3+NLSlfzH6U2qc9TNtG9v6RP Y6vU5q1flC/GgLWLJxJTHKkS/VEzsnQ= Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-4eed6ddcae1so23393597e87.0 for ; Tue, 25 Apr 2023 01:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1682409618; x=1685001618; 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=wJcVKVJA3HgnW7bSvVOddaHKG/ERA+dvV0Lub2llU+Q=; b=EOkcITT5Rq6XWK3ejRIWqvQTkMe0ymO3UjoLJxHU/nMXd+kJfjuDnngRLl0056SRHm ThA9qKaCSDNobvcy6jnV68/ursuWUy1LRvfcOiMnvJd6umM5gBHUqjEii9P0KObi7KGh BAFvn/jnFZdpnznd05oLdmPYj0b3vIN6GQEhpBNTdSfL4z+ZwxB1QMA9d150A+77EI3i plazI1uNEF7MssMeARqn6HbaKObj7K0qUBZHDm45tsXJspZswccglcpyVh33k/az8cYf 7sxktCdB7+YpplssXVz1+FDrVlx5NHqwNlTaeiZQzIojqvTIoBPoyIpW8YSps41cN/xv Ujqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682409618; x=1685001618; 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=wJcVKVJA3HgnW7bSvVOddaHKG/ERA+dvV0Lub2llU+Q=; b=ezrzqPfk9Sh6Va4cSPfhagiyfFE/wpTT32lz/qlXdTrW/41b6ziwGp8IgZUJfXNegG RucpDz8mVgzE/J7XkFgyu4l+f9i9y1Ag7/ULdS68uuYRNPdOI+3Y934zifgHM+u3OVaU i57+e93ee08CXckncHkSaF5ZIztdR0zYEorfNOa5OySQiFWkrseQQ49lWnksn1nyKYmT FaXE0i3TtWGZBYDoDe4At5ArLgimiY6guXUam89ioNOSiJ7rKL2UrpwshBN3cXbRas4o 9a1jZEfd+yEcbALo+p0fFxdgbWk9mPWq0Zcb/BDnQayRbP5B/fZTFGsTBPMFBXaz7ssI dhwg== X-Gm-Message-State: AAQBX9cjKZp8m8dWds0wLZaY4XM2hWUC0mht6gFUEVZ/aacBFdHETkdV LpOzGAdY7XRvPZryY+kYovd/bzmtQCkvvn9dJazdrQ== X-Google-Smtp-Source: AKy350ZxdfhaQD3I1+8v331wKiSztM8EPfAn2hc331pKYjbFsrskYvBdyUu9x9mXAh7RJVZWCXfYiGyWTG2NjZzD97c= X-Received: by 2002:a2e:9b87:0:b0:2aa:4550:9169 with SMTP id z7-20020a2e9b87000000b002aa45509169mr3099317lji.20.1682409617717; Tue, 25 Apr 2023 01:00:17 -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> <81c476f4-ef62-e4a6-0033-8a46a15379fd@intel.com> In-Reply-To: <81c476f4-ef62-e4a6-0033-8a46a15379fd@intel.com> From: Atish Kumar Patra Date: Tue, 25 Apr 2023 13:30:06 +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: AF107A0013 X-Rspamd-Server: rspam01 X-Stat-Signature: 6u1tb8t3cyxekj7sez657obk96udez1h X-HE-Tag: 1682409619-708527 X-HE-Meta: U2FsdGVkX1+5jEsXXv+YWrD7pX3wKkzF1h1/OAPDFm5U2RutqiPr8mfvehl2HcjJzM0j9Zivi33KsXySrQ9OFp5oe8Wg11CAbIf4/1tsay47hF3ZEZzjZ/49g9AX4/bGjQXhGOpHczH/KGDq7xzSgvA/deOes9R3wJshaj/6+2n91osdQmr37ySMcFl28pjKZH5YfZ71vs0+wwyfs0nTloHINyyKgvcCRK2Svq95ohmfeibPTOSPfQr2u1bJ+YmS0DG5Ork3conLvxgax0SQ4l7dLu8XETNhQx+qIh3shhSWG44NlCsQ+aOAY0lKsyo967XONtuCPflwh2B4CUuFJibE5fZ61NO5wrnXvaYonLp/CqxAC9Nd9lqb8BJlZJKnhtr8CuGw/5uh0xh/QpvgqdqZVJD0AE2WvmrSQC/+RTcORXr492ef7QDR9v9xzSHWrDTIAJ3ez8QYPOU66JAahJQjjbifZNPz5C7XoydGLOuta9CAVx5HwooI6bGQtRyzp0gmKC4GbTog58I//UlWKwTNYQiEeaVLs64oLz69pW4UVmA3h6z7XscnIaawV1eFRlwrD+6jMSzf87z3kNEUQnNyVrrE8N+IdXwDJY5hlUsR0tDkaW2EH3fm3hJb2NHIRY8DnXF+1+toGfD3kq0en4Pnqm3+UVzd8O9xSzTFc/zAc8cpDy0F0le0S6KCsqgKlXDOWIid9GvzKdQakHX7oF+pLgFKtVyvOwcCb96ngq/7OGPcRloVwfp6sMwfXepnjQL7+N0myp84kpw3Hhj4PxC6MGhf4zcLNUjohg6gjo279Yz4E1LR0MPNrHSUyCd3KYM/OLfX5CeXEDsqELX3ekrRlOiZ4A340z+QzMR3hynTMq7FekFMUh+EU9V+DgbZC2wCoJ1Hcp2gcFbznQz2GQtBvgJZHfpfDtaS9UfQMkV7uPPecqo3ELC2RP0c5ou1EhlQgFIbsrxUvySrbxh q4SLWrBN WwVakR3JZXcZVNDr7wmODLZJ3HEv1H+htCDji4/dXQSO4wnkyXjmP0ghTvCR61eVb7RBP7R5/9riYUyt9CioNJ925ShOGTMQj+mQhW0pQeYBqMCTp+W//AqfwLnxI7ePRHEtnDyEPbNLLIwBd+K4dTxE5z4dO47KNWSLm8GdEp/DxxOGIFcAF4PXD+FE/rM8ea75ClGdpGS2nrw2f4XBD5YbMt8r3M1r8aIPjlZl2poyJj6oqv6CqAav1OT1ZJCQyjXgcx7fbCV9E/epKq7hlwXQh8WSvLQhgHdgIeWZO6UgUXRIrV6JQjHsC8IUmN2hnFg2X0GIZDAGMPnNJq85xLNiNU6z5UQQ6kvXk8gjjIark7PU= 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 Mon, Apr 24, 2023 at 7:18=E2=80=AFPM Dave Hansen = wrote: > > On 4/21/23 12:24, Atish Kumar Patra wrote: > > On Fri, Apr 21, 2023 at 3:46=E2=80=AFAM Dave Hansen wrote:>> This callback appears to say to the host: > >> > >> Hey, I (the guest) am treating this guest physical area as MMI= O. > >> > >> 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. > How does this mechanism stop the host from emulating something outside > the designated region? > > On TDX, for instance, the guest page table have a shared/private bit. > Private pages get TDX protections to (among other things) keep the page > contents confidential from the host. Shared pages can be used for MMIO > and don't have those protections. > > If the host goes and tries to flip a page from private->shared, TDX > protections will kick in and prevent it. > > None of this requires the guest to tell the host where it expects MMIO > to be located. > > > 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. > > I'm not _quite_ sure what "guest initiated" means. But SEV and TDX > don't require an ioremap hook like this. So, even if they *are* "guest > initiated", the question still remains how they work without this patch, > or what they are missing without it. > Maybe I misunderstood your question earlier. Are you concerned about guests invoking any MMIO region specific calls in the ioremap path or passing that information to the host ? Earlier, I assumed the former but it seems you are also concerned about the latter as well. Sorry for the confusion in that case. The guest initiation is necessary while the host notification can be made optional. The "guest initiated" means the guest tells the TSM (equivalent of TDX module in RISC-V) the MMIO region details. The TSM keeps a track of this and any page faults that happen in that region are forwarded to the host by the TSM after the instruction decoding. Thus TSM can make sure that only ioremapped regions are considered MMIO regions. Otherwise, all memory outside the guest physical region will be considered as the MMIO region. In the current CoVE implementation, that MMIO region information is also passed to the host to provide additional flexibility. The host may choose to do additional sanity check and bail if the fault address does not belong to requested MMIO regions without going to the userspace. This is purely an optimization and may not be manda= tory. > > 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-sathyanarayana= n.kuppuswamy@linux.intel.com/ > > I don't really see the connection. Even if that series was going > forward (I'm not sure it is) there is no ioremap hook there. There's > also no guest->host communication in that series. The guest doesn't > _tell_ the host where the MMIO is, it just declines to run code for > devices that it didn't expect to see. > This is a recent version of the above series from tdx github. This is a WIP as well and has not been posted to the mailing list. Thus, it may be going under revisions as well. As per my understanding the above ioremap changes for TDX mark the ioremapped pages as shared. The guest->host communication happen in the #VE exception handler where the guest converts this to a hypercall by invoking TDG.VP.VMCALL with an EPT violation set. The host would emulate an MMIO address if it gets an VMCALL with EPT violation. Please correct me if I am wrong. As I said above, the objective here is to notify the TSM where the MMIO is. Notifying the host is just an optimization that we choose to add. In fact, in this series the KVM code doesn't do anything with that information. The commit text probably can be improved to clarify that. > I'm still rather confused here.