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 9F6FBC7618E for ; Thu, 20 Apr 2023 19:42:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1E96A900003; Thu, 20 Apr 2023 15:42:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 17A25900002; Thu, 20 Apr 2023 15:42:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 010DB900003; Thu, 20 Apr 2023 15:42:47 -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 E3116900002 for ; Thu, 20 Apr 2023 15:42:47 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BF23BC0445 for ; Thu, 20 Apr 2023 19:42:47 +0000 (UTC) X-FDA: 80702791974.18.DFB8C44 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf06.hostedemail.com (Postfix) with ESMTP id DCAE5180018 for ; Thu, 20 Apr 2023 19:42:45 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=MYgjyypq; spf=pass (imf06.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682019766; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Pfv2B7nnglGPY5lKeYYJGgG41JxY4YTi9gYldIZZ2FA=; b=Q49FiAOhTOYpk1I5tKVL/jU2R7fEQrFr0O+bp1cjZl2+QQ9FL9jQeGZli5q6EjgHQIVmNp 8sfLMDCf87T0meddFlty22Gv2NY+TXta7y6+JEWArsZp26jP1hBYp3ea9e3ehTCzNTe4p7 tc0LISnk10oMZvVPRrGKg+ovon39ois= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=MYgjyypq; spf=pass (imf06.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682019766; a=rsa-sha256; cv=none; b=oqer3cw8m+7yJT39iK3Z++VnkAqPT/w4L0KcUF+I5m+TzOA8OxrcQ9LXPVaZ2Y6BiPOJ2O yKS3Wzpg3Tl4gHilfHTWGkCjjPB/BFCwA9JDUYA0195smIsyE2KI6Ckw3Aoq+pdvGG9hnu EpCItwlpSX5n+i2cnCp1sB+19fCJ5Pw= Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-3f189819513so8684585e9.1 for ; Thu, 20 Apr 2023 12:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682019764; x=1684611764; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Pfv2B7nnglGPY5lKeYYJGgG41JxY4YTi9gYldIZZ2FA=; b=MYgjyypqswmQG6YtHr/gj3invlgUzYkrg/aPTuFdvQHZPL/YO5i4PF32XnyH1ZTGQz b734vWMYMbVsbbO/M9Wal3nSfPgVsr/VlA1Dm+srAgGFmF6Lp0bnhVphG5TcywnqlxEN otaG9qzSCRigVoIglNcR4SbSXcfghPUb5gc1+7NJi53TmMDnoeaSS5N3K/ZZKyvKhMOv my1Eafov4Ugs+psmIfSzuTUTr7xCxd+xW3qLejMV+2Hr7Qjwm/CzXTt6GkSmEByoLwgT dJD5ky+Ow1cBOXG8ZlV7MdBSFET0Faa917sHxhy0dYFJroREl5QPGJjugg/sG4kskK5K ewTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682019764; x=1684611764; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Pfv2B7nnglGPY5lKeYYJGgG41JxY4YTi9gYldIZZ2FA=; b=QiS1VXTMa1GQ7K7A9Oze5vzsxvaIMBakBvUWuFswCx4O8VfCxOK4GOXQHU+q/fqKVX 1SPj0iJxpdPAifKW4rToNv+aCG+N034VTYuV/85p557h842JRAsjtmUrdUhnhauKe3F0 TkoUWW+Oxa+I5yDdzg7lgAsWneKTUl+DAiYJ5mNoJx9wrXYhMU8tdpuIpRGC91cOen4J mvMkKK2CrlPFsI5rksf17I/Dk+adg2KnEgCcmqSD1n9RP5dC9GNXsloPfvsMZQWgaOuU 3IfJU2hGAQqSgQufUpenXfMQH5Rp7rvMg/jLltcBZbryx/We7nfgSeDbnGz4V7If9a+I +VOQ== X-Gm-Message-State: AAQBX9dR1keHnmqOoJQfSlJwn2Pzpq8t1OvKncbCiImrKFigHXHN1haO W635BjsHDnM2acvh/fnCKvY= X-Google-Smtp-Source: AKy350avq0CExGtf4fiebF3FQzRiPIJEHCbJzrk50zC+WfWDQsglBM9pgQzdlXh/LaLmbuvNYNl/2A== X-Received: by 2002:a7b:ca43:0:b0:3eb:3945:d405 with SMTP id m3-20020a7bca43000000b003eb3945d405mr34247wml.38.1682019764130; Thu, 20 Apr 2023 12:42:44 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id j32-20020a05600c1c2000b003f173987ec2sm6257438wms.22.2023.04.20.12.42.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Apr 2023 12:42:43 -0700 (PDT) Date: Thu, 20 Apr 2023 20:42:42 +0100 From: Lorenzo Stoakes To: Atish Patra Cc: linux-kernel@vger.kernel.org, Rajnesh Kanwal , Alexandre Ghiti , Andrew Jones , Andrew Morton , Anup Patel , Atish Patra , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , 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 Subject: Re: [RFC 01/48] mm/vmalloc: Introduce arch hooks to notify ioremap/unmap changes Message-ID: References: <20230419221716.3603068-1-atishp@rivosinc.com> <20230419221716.3603068-2-atishp@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230419221716.3603068-2-atishp@rivosinc.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DCAE5180018 X-Stat-Signature: bjt1hk6d3ujjm5tyb9i8sdrqpi5f6qud X-Rspam-User: X-HE-Tag: 1682019765-442557 X-HE-Meta: U2FsdGVkX18B0k43OF/Mu8vmGIk2Kx+h6uX+pkTQ/9IvG2N+xPcjm5qvaRB32DYFOOpvag8mX8N7KpghgoV838fUq25ctdG/U2hbp2qrXoqruqoBXOaORjWV0qG6G/QkplOm1faa0spH+VwP16gBmANKsKCyt+vQ8yx9XgHCBvCI5ZuVmAPalYSmTS77Hz3Kb/vQj5WSRc+nkz6YjjiTvfJHdpfSZ4FxAIfYQKj13EHde4CZk7ZBEhMuAq3ZF0FeIqXPRA5Mf+ZjE3CwjebItN3sb7yf/eoBIDg3d1nxVCh7c6QxdO7Au0hL0YXlV/+ZXMVuCfQmZSTTKBNMyg441Ae4tQEELAqL00SHqjr8etnbMsXqDVZdS76DXHHBhtYiapRiGOOeenTEE4qtVfSFydjFMfaui184vDSYPR2jsu770FLzgosqom8sfeFiPxPBpARaxCu+c0iRoP65wOgxrpTHOXl4Ka6ezKU95VkJsW2mF43Eq7TOTf7+B/qM6zU79/VXTwvea60B7cI4aSdAykdz8vyPGN7mlQ+MUyK7064XcdeKULSiZAL606JldGikTgkm6bqLXlR/VS3AHTIcqcco3rSedP9f8OBfFDf0SErWj0reGA3bFYIsXGZt5Esu8UXn6Ii/xoPZovkujRE1wfNOIKzrU8kWIOCoCL0kGIDk01fVTgGsUU03FffIdkLbL+fMW8p46vsemrevLDZWSOtOjA+DlPfLuOgnxtCI+bt9KB1eJelIRrWPL0Q8kFbk2LrbbWJFYAMnMUfdp0FVO/HY1MH66q7wdvfqsah5z9xu1TAeaEjYxzyIDvPmbUDD/SF6xEudgLDI3S7X/fm33K1LlKIZjOT2FeX9CGygltnTb/LXV75pu4jWybKIGADYCtuAWR67/VwzgxTwlGTixgWmYp6AqR/yNU/PkCXrWoatChynBdLXIxO14sbnGLZXq17f2jw19tOgdSny+bv Zh2M1sU3 jaZdEjrQ3Bc0AzehqKP5mmgplrWAvoUrkmkwGJM51gFddCA0gL3vpp63k+Z76UXlq++JZEdwjHN9wgWqWGm9iRmjWrcDhZK9dfl29QBaS4O55QocWqFhw8hZE0WDDUAoRv3FHpPTl+Bz6CerIg36xdCnGbwFe3ZTGLAz4JfhGPhdGWxTkIcEtk+5eYizQS14paysYri3vuMiXNub/u4TiLNd06nA2S1ymd5kKG8BlBIa2Ugws0VJ/D7l84Qgrn2V2GRvHYY4pHqK4PTSvTsVap7c2QEXYJ200XJaOiqjoeEFWeqT9SVdeHddKCkNbqFke+zGLk2zsj7d1lq/vCSkl7Sw2AQ9dy65TRGd4EO4yvMCFbm9KucUzNbcgfQ90EWkt2Bg4xLBSECf9oKcdWl4OV2P3javXh9h/wcJwkDyAzHDlyLIs1sT7HDBDzrAS0Uy7qVVU 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: 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 for future I'd appreciate a cc- :) 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 guest. > > Add a pair if arch specific callbacks to track the ioremapped regions. Nit: typo if -> of. > > 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 you 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 good to know! > > 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 somewhere, as it does hide the call paths quite effectively. > 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, unsigned 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(vm)); > + 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 specified in the original hook. Is this intended? > kfree(vm); > } > EXPORT_SYMBOL(vunmap); > -- > 2.25.1 >