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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 4957DC4332F for ; Thu, 2 Sep 2021 18:07:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8326610A2 for ; Thu, 2 Sep 2021 18:07:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C8326610A2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C641C6B0071; Thu, 2 Sep 2021 14:07:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C15626B0072; Thu, 2 Sep 2021 14:07:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B02696B0073; Thu, 2 Sep 2021 14:07:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id 9DEB16B0071 for ; Thu, 2 Sep 2021 14:07:40 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 542D482F3C16 for ; Thu, 2 Sep 2021 18:07:40 +0000 (UTC) X-FDA: 78543416280.31.209EACE Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf03.hostedemail.com (Postfix) with ESMTP id 120A730000A4 for ; Thu, 2 Sep 2021 18:07:39 +0000 (UTC) Received: by mail-pl1-f180.google.com with SMTP id e7so1704941plh.8 for ; Thu, 02 Sep 2021 11:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vRIjmhyCmvhzoncqRr/4/DZW11FScO6N7+EAyatLST8=; b=XMesfIC0+k3N01cWkq/7yrPStcBFfCtU0Xt5gHxmO6bSOqNzOd/s/+OIcyxTtPL0UB Zng0Xr0YFco/Xf9QMwJ1lFRNjwY2PQU2HaoU373axgK5j5uox9fzWYNliilkTt2b7635 V91czhYOVkLyFSSHgMICNRA+1MUJvkWBhBtJCw+K3Pz7KZzwdTemN3cZWwl6TG6/x/VY gVXwVoSa8S7795y2jXzfuGxwg/3NV2fxcHJ+poYDNAV/6rPM1QeRY/Xp9i6iTn+hetnE jzukgzWZ2XX4nyFUgxq4UKt32X2sBiiT9MgweOPYXEtFj2L1DKwPsQuH2MLeX33munh9 iWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vRIjmhyCmvhzoncqRr/4/DZW11FScO6N7+EAyatLST8=; b=OJL22cKrpJl+k9M3cRqgNj5xi+fYHYWe13m3Toih6AzRONn2CpHX1sZEpSP4tEsku4 gGo3gV4Ezw2m0jBMBHj2aeVE0uMOb4jyGA/kjiv7gEnrqKOZTuNrlxWHVJNu+TfHp1Oo ijw2BkPvq9Q58gtFmZrW9d7YezT654d7BzNnH5MR8dkv8MCEbdHYBGv+YIv03/kBmqX+ bigLwsoRtES6sFUJD2X/hVHMQfrsFuIkDjLTGQ5Z4mBmd1G0cuXxCTvDR1lmqAqzAnRd 0M04VM/10mHf9RtguuGP0ICpCznCIHxOm3j50ABIAvgJwKX79+ngdqS+zEGYBcu5uTcn l0LA== X-Gm-Message-State: AOAM531hOCvyahvLwVT7F3vCy9ajZk4WtFkscp7dDVNjtBpTZ/quGw6t 5x56mhBCezf8tLv6qoG+MxjaKGtjirs+/JZl9b+q0A== X-Google-Smtp-Source: ABdhPJzISzTRdHEt3HEJe+ostypx1drj+Ux+3k9nfUpn2fvhtymn5ZGWoVXBoZmcXh6gl6QtltkADP+8aToUdn6EVdg= X-Received: by 2002:a17:902:e550:b0:137:734f:1d84 with SMTP id n16-20020a170902e55000b00137734f1d84mr4046482plf.27.1630606059035; Thu, 02 Sep 2021 11:07:39 -0700 (PDT) MIME-Version: 1.0 References: <20210825034828.12927-1-alex.sierra@amd.com> <20210825034828.12927-4-alex.sierra@amd.com> <20210825074602.GA29620@lst.de> <20210830082800.GA6836@lst.de> <20210901082925.GA21961@lst.de> <11d64457-9d61-f82d-6c98-d68762dce85d@amd.com> <20210902081826.GA16283@lst.de> In-Reply-To: <20210902081826.GA16283@lst.de> From: Dan Williams Date: Thu, 2 Sep 2021 11:07:28 -0700 Message-ID: Subject: Re: [PATCH v1 03/14] mm: add iomem vma selection for memory migration To: Christoph Hellwig Cc: Felix Kuehling , "Sierra Guiza, Alejandro (Alex)" , Andrew Morton , Linux MM , Ralph Campbell , linux-ext4 , linux-xfs , amd-gfx list , Maling list - DRI developers , Jason Gunthorpe , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel-com.20150623.gappssmtp.com header.s=20150623 header.b=XMesfIC0; spf=none (imf03.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.214.180) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 120A730000A4 X-Stat-Signature: 7udeepqyfepmotgo696iua1uwm9okcrd X-HE-Tag: 1630606059-443773 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 Thu, Sep 2, 2021 at 1:18 AM Christoph Hellwig wrote: > > On Wed, Sep 01, 2021 at 11:40:43AM -0400, Felix Kuehling wrote: > > >>> It looks like I'm totally misunderstanding what you are adding here > > >>> then. Why do we need any special treatment at all for memory that > > >>> has normal struct pages and is part of the direct kernel map? > > >> The pages are like normal memory for purposes of mapping them in CPU > > >> page tables and for coherent access from the CPU. > > > That's the user page tables. What about the kernel direct map? > > > If there is a normal kernel struct page backing there really should > > > be no need for the pgmap. > > > > I'm not sure. The physical address ranges are in the UEFI system address > > map as special-purpose memory. Does Linux create the struct pages and > > kernel direct map for that without a pgmap call? I didn't see that last > > time I went digging through that code. > > So doing some googling finds a patch from Dan that claims to hand EFI > special purpose memory to the device dax driver. But when I try to > follow the version that got merged it looks it is treated simply as an > MMIO region to be claimed by drivers, which would not get a struct page. > > Dan, did I misunderstand how E820_TYPE_SOFT_RESERVED works? The original implementation of "soft reserve" support depended on the combination of the EFI special purpose memory type and the ACPI HMAT to define the device ranges. The requirement for ACPI HMAT was relaxed later with commit: 5ccac54f3e12 ACPI: HMAT: attach a device for each soft-reserved range The expectation is that system software policy can then either use the device interface, assign a portion of the reservation back to the page allocator, ignore the reservation altogether. Is this discussion asking for a way to assign this memory to the GPU driver to manage? device-dax already knows how to hand off to the page-allocator, seems reasonable for it to be able to hand-off to another driver.