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 4DE73C77B73 for ; Thu, 20 Apr 2023 22:01:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B73FD900003; Thu, 20 Apr 2023 18:01:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B23BB900002; Thu, 20 Apr 2023 18:01:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9ECA8900003; Thu, 20 Apr 2023 18:01:31 -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 913A1900002 for ; Thu, 20 Apr 2023 18:01:31 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4C24BAC4C1 for ; Thu, 20 Apr 2023 22:01:31 +0000 (UTC) X-FDA: 80703141582.14.2262E7A Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf01.hostedemail.com (Postfix) with ESMTP id 904FA4001C for ; Thu, 20 Apr 2023 22:01:27 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=XccRPyOw; spf=pass (imf01.hostedemail.com: domain of atishp@rivosinc.com designates 209.85.216.54 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=1682028087; 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=m2Ev3XkqPH6pBRfYHzJ+uQ7XVHtYSI/8IWEmQRBv/YI=; b=K0Ynv7j4eAf9RiTGN8EgPzMEm3uBL2yNerxhdyCgx9NCFTiijbzcN7BBQSh0tpTX87SMaD xnuf5nYQGFaxwpfdaWQ+wvLD8hYeK4qnDX6E2RdN9uUG/17mJXhCDU1JulO1/zHH89CoDw M3oyq2gSB09hWT0CboJEc5IBvw7qp4I= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=XccRPyOw; spf=pass (imf01.hostedemail.com: domain of atishp@rivosinc.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=atishp@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682028087; a=rsa-sha256; cv=none; b=6oWfOYfk4UsyHg3Bu4ZzZNjVad5y2qi6KhMUT2KrciRy6gZXj6yHrmIUOMbHcsn+SO9Fl4 cewu+DH23V7DZRYO8z/vBx4WqIdeS6uCqtqM6WOqKp3ByhVMq0VbvWtOsn7jU1VtY4nVuk a0G3HSKOxySDnEeYxPa9g89dW3/aCyw= Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-24986ade373so1320067a91.2 for ; Thu, 20 Apr 2023 15:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1682028086; x=1684620086; 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=m2Ev3XkqPH6pBRfYHzJ+uQ7XVHtYSI/8IWEmQRBv/YI=; b=XccRPyOwGtCXf7M5O+HNfS7PIZwaQD/v87OkbY9kPKXbSXCwAHUwb77DmpKXQM0oF7 R0iGe67jW+b5DNWOVTJNemJXy3OKOX6KdYoUmETuzx9PGEbJFJQ2pUniMRMuVPMdDiGU /5tCrXANgIgLRaYyadJDbdo+RbIOZFK426WywYo54ew0ofNLXcABU5+/CMzqIREzPHeY nozuQwG7Zt6NpmqIblntxNB1TQq9MjpSBvyrh0FYtiq26IkPB90nc3IN0Z5SPpjDuFAg Uf2dafkB6vN/Ipj35Qgs/T7S7nQT6pBp/glwP+uShCgN0NssPyN9BTUsrhgWhmezZtGB kVTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682028086; x=1684620086; 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=m2Ev3XkqPH6pBRfYHzJ+uQ7XVHtYSI/8IWEmQRBv/YI=; b=K+TYd6dxJ1Bd1p+lKhYEvCzFYVP+Bm3C4DOFVUIjcgkJ0kPBD69+pkVt3gLjihpJnq 4D4ghbw5JySUPcu8EpLTL7PgYkyBbRzUWSnVf7rgbbXSrsGDhiL5ZmPOQ4dLZOD5Sc6i fg/qqLcyF2OG/IXfy2mkosOnThV62dnyiI6pgmvv1FyZ3ksiadsLR6wH+s/ymvmdz35C U6+UQkB9UdrZHDKYhnyn7SKurfjsBWBu5ID1tCQKr38apTHRaU/rGFn8wbzhN1vWXLXD KZBq6kM6TxdGsVlq/MGha2t9oJXR1h4BZ7rnHzZ/ugDo8Qx+ZiAf72ZCYJkNRMPtITjI GqPA== X-Gm-Message-State: AAQBX9cUv6NicinXZTmVSI6Rk3uGHpIPV9JADkvhA0CNx6JF6Gd3F2MG aSSvrzb3tZqNmxNl/YFS1jTUQxZA0a/HQQ/NNsTkBQ== X-Google-Smtp-Source: AKy350ZODjmhBgPpSK9yTOVPr1QR4R227MhIwe3aNJJTXaij0JPaPQ4lg0m0d3q6HUIib6fUODiqrkndxcAY/A+hkAo= X-Received: by 2002:a17:90a:5509:b0:247:a272:71d1 with SMTP id b9-20020a17090a550900b00247a27271d1mr3035541pji.7.1682028086370; Thu, 20 Apr 2023 15:01:26 -0700 (PDT) MIME-Version: 1.0 References: <20230419221716.3603068-1-atishp@rivosinc.com> <20230419221716.3603068-2-atishp@rivosinc.com> In-Reply-To: From: Atish Kumar Patra Date: Fri, 21 Apr 2023 03:31:15 +0530 Message-ID: Subject: Re: [RFC 01/48] mm/vmalloc: Introduce arch hooks to notify ioremap/unmap changes To: Lorenzo Stoakes 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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 904FA4001C X-Rspam-User: X-Stat-Signature: 74x19ureekrb5swjghfpzn9zar9czyno X-HE-Tag: 1682028087-407653 X-HE-Meta: U2FsdGVkX19pzCiBmvoJWjfsLawz1sGxkvnyXtAR3UZT9+vj2omf22W919hHCfc3EYZCAxMQk70CcdVhH9YYthWrS5MLwL/WXZKqaOD8hIbIVYLlidn4Q7R51QvcCapk8Z8JpvsXF7jsjrP0HwfI3U4d8ZqH3jcx17PClwoDaEgIlDouRSo2vBThnNj5sQl7IRXFe5L6ypIcTWrf4KU+NaBPcXPetConinsWQlj5lGsrp9uQNT4ZWaRgJ9d3KAt1EZQVehey/Xm2Fk/R65Q2nBWNPNhBOC3BvEt2OmWGEJDA+ZobvETltTnr9GKIR5g11xjpvvPs8JbILhAWFDwuh4X4gYcjdB/rrBkpp6Xw7HI0QmGNi+OJCSoGmhdGT9RSvwkD0fs/7HVa1XcChCkZ1lPJY3bto/zUBVO7cLLKhyCmg4/1NQu3Xf3BD1QLr7Hdo27OXPJuAVArfnZUDwklPI7aFkWus8v90epl7SVS2eVH4beAtot2LKSuo9zarUV/hoOLqPcM+JLeMhjH/VTyx/Zq/UGL+7FfvsuNHBnz83CqcGOMZyRn2WWtaVYH+M4Y7jhOojITWMRSgyIgTMXslTym00iA4dVc3Mt+3HckY5hJjzleeVdkAimNAWf2NbZJVfJzSan2nAyQE3Tmo0NmMvRL+agIMR6hvSy17aVYPiocJWeEnkHjjgLz37lWuZa2cFP3pWvyPMDrFgD19vjdHBtA+xAEfD2M4td1Oyw++BNV6gi9sIWVYcLFChZi5SodPCUEZnlsDvv71pL7ybqor4WdIWaclOkYKdJ55VHqalKzBymo8U1/suE+TrcLVKDrrKhyysaV4t5sdIQQ4hsPg9dh1x5dzEexYtRHGe0PGJ6ppfXUMtSnARCpYpXNyPE1KFBS+uU99jEReJD9ML4YyxzBuDu6TkexctonfGizSEArajT2CVV0EZJcbxkJyHI0H905Ipwi/nP/S+8KAqx W+dKrmxt DYCB4X/keB0tn80uBl49AGdLKp8MFNN+vug5ZoG4Um4Gw2pEiYXJ/Nsf2550COO83piQIK1gLxKz/U7+4mPCo0FcS6q+KPSB6c7T890TofjTf4cLQAaUxwUL6PKu/+3pFKWT5Np+crmoHHJgN1rCgBVAhXn9ESN0NBVI+FPxEWt73kvd0iY61kqMOKMpVPekuhFZfjAGojziQxMqKatgJPqb1gPkdFxaHdsCh4LtzCTeQbtbYY2W8bvN67U05SyqjOBZ3Hpdh7Jhbf/tNGVsRCYLZ8ZS/YubKovYAsH+PTNylQfU1Noob3U50KX1rs2+La7FS1klYncZrAbzexOdFQKMNZd5AjS0RXofttdnKj5tUL6l7s6DGV24lG250jAv3DuKpVyCPEAizpgzALitD+yzaWZUBm8IrOFTaYe2xxBikNE9o0ZHkRltmhIgn9yRqeKUv6WS2z/9HzM9nVJxzmh+MWKIQpdmB1xqK1CkGt2xtNhFZMyLmwCnVKw== 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 1:12=E2=80=AFAM Lorenzo Stoakes wrote: > > I'm a vmalloc reviewer too now -next/mm-unstable get_maintainer.pl should= say > so, but forgivable because perhaps you ran against another tree but FYI f= or > future I'd appreciate a cc- :) > Ahh. Thanks for pointing that out. I see the patch for that now https://lkml.org/lkml/2023/3/21/1084 This series is based on 6.3-rc4. That's probably why get_maintainer.pl did not pick it up. I will make sure it includes you in the future revisions. > On Wed, Apr 19, 2023 at 03:16:29PM -0700, Atish Patra wrote: > > From: Rajnesh Kanwal > > > > In virtualization, the guest may need notify the host about the ioremap > > regions. This is a common usecase in confidential computing where the > > host only provides MMIO emulation for the regions specified by the gues= t. > > > > Add a pair if arch specific callbacks to track the ioremapped regions. > > Nit: typo if -> of. > Fixed. Thanks. > > > > This patch is based on pkvm patches. A generic arch config can be added > > similar to pkvm if this is going to be the final solution. The device > > authorization/filtering approach is very different from this and we > > may prefer that one as it provides more flexibility in terms of which > > devices are allowed for the confidential guests. > > So it's an RFC that assumes existing patches are already applied or do yo= u mean > something else here? What do I need to do to get to a vmalloc.c with your= patch > applied? > > I guess this is pretty nitty since your changes are small here but be goo= d to > know! > Here is a bit more context: This patch is inspired from Marc's pkvm patch[1= ] We haven't seen a revised version of that series. Thus, we are not sure if this is what will be the final solution for pKVM. The alternative solution is the guest device filtering approach. We are also tracking that which introduces a new set of functions (ioremap_hardned)[1] for authorized devices allowed for. That series doesn't require any changes to the vmalloc.c and this patch can be dropped. As the TDX implementation is not ready yet, we chose to go this way to get the ball rolling for implementing confidential computing in RISC-V. Our plan is to align with the solution that the upstream community finally agrees upon. [1] https://lore.kernel.org/kvm/20211007143852.pyae42sbovi4vk23@gator/t/#mc= 3480e2a1d69f91999aae11004941dbdfbbdd600 [2] https://github.com/intel/tdx/commit/d8bb168e10d1ba534cb83260d9a8a3c5b26= 9eb50 > > > > Signed-off-by: Rajnesh Kanwal > > Signed-off-by: Atish Patra > > --- > > mm/vmalloc.c | 16 ++++++++++++++++ > > 1 file changed, 16 insertions(+) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index bef6cf2..023630e 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -304,6 +304,14 @@ static int vmap_range_noflush(unsigned long addr, = unsigned long end, > > return err; > > } > > > > +__weak void ioremap_phys_range_hook(phys_addr_t phys_addr, size_t size= , pgprot_t prot) > > +{ > > +} > > + > > +__weak void iounmap_phys_range_hook(phys_addr_t phys_addr, size_t size= ) > > +{ > > +} > > + > > I'm not sure if this is for efficiency by using a weak reference, however= , and > perhaps a nit, but I'd prefer an arch_*() that's defined in a header some= where, > as it does hide the call paths quite effectively. > Sure. Will do that. > > int ioremap_page_range(unsigned long addr, unsigned long end, > > phys_addr_t phys_addr, pgprot_t prot) > > { > > @@ -315,6 +323,10 @@ int ioremap_page_range(unsigned long addr, unsigne= d long end, > > if (!err) > > kmsan_ioremap_page_range(addr, end, phys_addr, prot, > > ioremap_max_page_shift); > > + > > + if (!err) > > + ioremap_phys_range_hook(phys_addr, end - addr, prot); > > + > > return err; > > } > > > > @@ -2772,6 +2784,10 @@ void vunmap(const void *addr) > > addr); > > return; > > } > > + > > + if (vm->flags & VM_IOREMAP) > > + iounmap_phys_range_hook(vm->phys_addr, get_vm_area_size(v= m)); > > + > > There are places other than ioremap_page_range() that can set VM_IOREMAP, > e.g. vmap_pfn(), so this may trigger with addresses other than those spec= ified > in the original hook. Is this intended? > Thanks for pointing that out. Yeah. That is not intentional. > > kfree(vm); > > } > > EXPORT_SYMBOL(vunmap); > > -- > > 2.25.1 > >