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 D6D9AC433EF for ; Tue, 21 Dec 2021 14:14:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 299086B0071; Tue, 21 Dec 2021 09:14:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 247E76B0073; Tue, 21 Dec 2021 09:14:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1112E6B0074; Tue, 21 Dec 2021 09:14:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id F34C26B0071 for ; Tue, 21 Dec 2021 09:14:06 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id ACD96180FE11F for ; Tue, 21 Dec 2021 14:14:06 +0000 (UTC) X-FDA: 78941995692.26.60027EB Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by imf09.hostedemail.com (Postfix) with ESMTP id 8BC3214003D for ; Tue, 21 Dec 2021 14:14:01 +0000 (UTC) Received: by mail-pj1-f53.google.com with SMTP id lr15-20020a17090b4b8f00b001b19671cbebso3332767pjb.1 for ; Tue, 21 Dec 2021 06:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:references:from :in-reply-to:content-transfer-encoding; bh=49xep4tw+Sc58A5ggDCsUXirsXZoTYPyS/fFq9/fups=; b=Zj+tsKhaKnFGTTehTjsbNd7QBIWT4onLKQceEdXAL9l4zZhRAkvzDhLVpI++Zxp0CV yFGbCyZPoIE+x9wRrmjL8VR3X8r2wp6szYmVWU42ta2Fpg8QjpLtkaHOL2aVscv/nQyG VOvlSSLrAgAxh+y7mojj1B1LGCKSjcRLbZ/LcNCKsmDuBhCSv364/7H6huzBtfyME/ey nJcDNxErTjEDOWoRsq/oWS6zCCchMPdXgSqsGc5+1hyC+nxNOlIRaVwZmXh3QsLplJYx 74TX7SY3Ni/744+yHBzhiAkatAAlzoFJVWufSBpdBPMYp1yD+4c52z47xwd+0HFlLZG+ MVhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:from:in-reply-to:content-transfer-encoding; bh=49xep4tw+Sc58A5ggDCsUXirsXZoTYPyS/fFq9/fups=; b=UOO0K55oAfsTvEvwLP/wTKhrLuxNYDCoq8fgs3qZtgXRpxQldmMqb6Vk+yzm/g2nfS S3DSN4YRzXMo0LOhSKisalFciFxIUlFyREzXmv7xBnNO+4L9kk50scqrVj51bm2VY+O2 9UonWCPCAWqrez1J9W1IJ5YssP3ntnW4OJo3zEEoTLWbRgF4lPAb5KocpX5XIJ4cP+9t uU/+B0Om1Mj37eQuKRoq+VuMeInWPByupjlnOMegzhor5WaiDYYBgm63J7pTJuIHjPg1 +iNKyLR2l7SBMTcT4l3DXuGdyWLoEk+t+bVQVVxqQ5lBYJ3mP1ixX8544+HXpIRegHPQ aubA== X-Gm-Message-State: AOAM532syi44O8q6A1bwN3tWEpuCv270yX5b5sE4/s3X9QdYTcTAK356 PtkHUKhLm+JjYeshidOzoIA= X-Google-Smtp-Source: ABdhPJwQ2UXFPvi6+y4UUUWSah3wS8SPHfOvFOdY0KYDddv+eQA+gfz+M8hIUGkqk8v6rsYG703Bjw== X-Received: by 2002:a17:902:be06:b0:148:ae06:5e30 with SMTP id r6-20020a170902be0600b00148ae065e30mr3453799pls.93.1640096045177; Tue, 21 Dec 2021 06:14:05 -0800 (PST) Received: from [30.240.97.243] ([205.204.117.107]) by smtp.gmail.com with ESMTPSA id e15sm13499732pga.53.2021.12.21.06.14.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Dec 2021 06:14:04 -0800 (PST) Message-ID: <75f27767-a57c-da5c-20ba-f11e0c261692@gmail.com> Date: Tue, 21 Dec 2021 22:14:01 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [Question] mm/resource: a mistake to use IORESOURCE_SYSRAM instead of IORESOURCE_SYSTEM_RAM? To: David Hildenbrand , linux-mm@kvack.org References: <92d3d4c3-5756-5df5-36e1-ad2e99aef21f@redhat.com> From: Eric Ren In-Reply-To: <92d3d4c3-5756-5df5-36e1-ad2e99aef21f@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Rspamd-Queue-Id: 8BC3214003D X-Stat-Signature: frzzqbmuzyfm8fbnshezzmo3ewp5axta Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Zj+tsKha; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of renzhengeek@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=renzhengeek@gmail.com X-Rspamd-Server: rspam11 X-HE-Tag: 1640096041-701418 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, =E5=9C=A8 12/21/21 6:40 PM, David Hildenbrand =E5=86=99=E9=81=93: > On 21.12.21 11:14, Eric Ren wrote: >> Hi David, > Hi Eric, > >> I feel confused on this piece of code: >> >> ``` >> void release_mem_region_adjustable(resource_size_t start, >> resource_size_t size) >> { >> ... snip >> /* >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * All memory region= s added from memory-hotplug path have the >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * flag IORESOURCE_S= YSTEM_RAM. If the resource does not have >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * this flag, we kno= w that we are dealing with a resource coming >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * from HMM/devm. HM= M/devm use another mechanism to add/release >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * a resource. This = goes via devm_request_mem_region and >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * devm_release_mem_= region. >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * HMM/devm take car= e to release their resources when they want, >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * so if we are deal= ing with them, let us just back off here. >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 */ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!(res->flags & IORESO= URCE_SYSRAM)) { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 b= reak; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> ``` >> >> The comment says IORESOURCE_SYSTEM_RAM while IORESOURCE_SYSRAM is >> actually used. >> Is this a mistake? > IORESOURCE_SYSTEM_RAM is really just (IORESOURCE_MEM|IORESOURCE_SYSRAM) > > So it's sufficient to check for IORESOURCE_SYSRAM ("release_mem_region" > implies that it's a mem region) Thanks. My doubt is cleared. > >> The reason why I come to read about this is that, I got -EEXIST error = from >> add_memory_driver_managed() when I want to virtio_mem regions sitting = on >> Reserved >> memory region like this in /proc/iomem: >> ``` >> fffc0000-183fffffff : Reserved >> =C2=A0 100000000-183fffffff : System RAM (virtio_mem) >> =C2=A0=C2=A0=C2=A0 1820000000-183fffffff : System RAM (virtio_mem) /= / --> plugged MB >> ``` > That looks broken. > > Where did the __request_mem_region(IORESOURCE_SYSTEM_RAM | > IORESOURCE_EXCLUSIVE) go? > > How does the memory end up being marked reserved? > > If it's exposed via a firmware-provided memory map, that's a spec > violation ... Please see below. > >> EEXIST error happens after plug -> unplug -> plug testing, because the >> hot-added region remains after unplug. The hot-added region is under >> Reserved region. The IORESOURCE_SYSRAM flag check will skips to handle >> children of the Reserved region. >> Thanks in advance! > Can you elaborate more on the setup / use case? Yes, with my special setup, the result above is expected, because=20 "Reserved"=C2=A0 resource does not have IORESOURCE_SYSRAM flag. I'm doing a hack experirement, that makes virtio_mem use physical memory=20 from reserved memory by using memmap=3Dxxx kernel parameter, instead of using device memory=20 backended my hypervisor. Thanks for your help, and sorry for the noise ;-=EF=BC=89 Eric > > >