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,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 27452C4338F for ; Fri, 20 Aug 2021 04:21:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E821F60FBF for ; Fri, 20 Aug 2021 04:21:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229888AbhHTEWf (ORCPT ); Fri, 20 Aug 2021 00:22:35 -0400 Received: from verein.lst.de ([213.95.11.211]:39627 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229457AbhHTEWe (ORCPT ); Fri, 20 Aug 2021 00:22:34 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id E02696736F; Fri, 20 Aug 2021 06:21:51 +0200 (CEST) Date: Fri, 20 Aug 2021 06:21:51 +0200 From: "hch@lst.de" To: Michael Kelley Cc: Tianyu Lan , KY Srinivasan , Haiyang Zhang , Stephen Hemminger , "wei.liu@kernel.org" , Dexuan Cui , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "x86@kernel.org" , "hpa@zytor.com" , "dave.hansen@linux.intel.com" , "luto@kernel.org" , "peterz@infradead.org" , "konrad.wilk@oracle.com" , "boris.ostrovsky@oracle.com" , "jgross@suse.com" , "sstabellini@kernel.org" , "joro@8bytes.org" , "will@kernel.org" , "davem@davemloft.net" , "kuba@kernel.org" , "jejb@linux.ibm.com" , "martin.petersen@oracle.com" , "arnd@arndb.de" , "hch@lst.de" , "m.szyprowski@samsung.com" , "robin.murphy@arm.com" , "thomas.lendacky@amd.com" , "brijesh.singh@amd.com" , "ardb@kernel.org" , Tianyu Lan , "pgonda@google.com" , "martin.b.radev@gmail.com" , "akpm@linux-foundation.org" , "kirill.shutemov@linux.intel.com" , "rppt@kernel.org" , "sfr@canb.auug.org.au" , "saravanand@fb.com" , "krish.sadhukhan@oracle.com" , "aneesh.kumar@linux.ibm.com" , "xen-devel@lists.xenproject.org" , "rientjes@google.com" , "hannes@cmpxchg.org" , "tj@kernel.org" , "iommu@lists.linux-foundation.org" , "linux-arch@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "netdev@vger.kernel.org" , vkuznets , "parri.andrea@gmail.com" , "dave.hansen@intel.com" Subject: Re: [PATCH V3 12/13] HV/Netvsc: Add Isolation VM support for netvsc driver Message-ID: <20210820042151.GB26450@lst.de> References: <20210809175620.720923-1-ltykernel@gmail.com> <20210809175620.720923-13-ltykernel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org On Thu, Aug 19, 2021 at 06:14:51PM +0000, Michael Kelley wrote: > > + if (!pfns) > > + return NULL; > > + > > + for (i = 0; i < size / HV_HYP_PAGE_SIZE; i++) > > + pfns[i] = virt_to_hvpfn(buf + i * HV_HYP_PAGE_SIZE) > > + + (ms_hyperv.shared_gpa_boundary >> HV_HYP_PAGE_SHIFT); > > + > > + vaddr = vmap_pfn(pfns, size / HV_HYP_PAGE_SIZE, PAGE_KERNEL_IO); > > + kfree(pfns); > > + > > + return vaddr; > > +} > > This function appears to be a duplicate of hv_map_memory() in Patch 11 of this > series. Is it possible to structure things so there is only one implementation? In So right now it it identical, but there is an important difference: the swiotlb memory is physically contiguous to start with, so we can do the simple remap using vmap_range as suggested in the last mail. The cases here are pretty weird in that netvsc_remap_buf is called right after vzalloc. That is we create _two_ mappings in vmalloc space right after another, where the original one is just used for establishing the "GPADL handle" and freeing the memory. In other words, the obvious thing to do here would be to use a vmalloc variant that allows to take the shared_gpa_boundary into account when setting up the PTEs. And here is somthing I need help from the x86 experts: does the CPU actually care about this shared_gpa_boundary? Or does it just matter for the generated DMA address? Does somehow have a good pointer to how this mechanism works?