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=-9.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 8AE26C35247 for ; Tue, 4 Feb 2020 18:20:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 25DD92082E for ; Tue, 4 Feb 2020 18:20:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dBA6JtY8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 25DD92082E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6B6926B0005; Tue, 4 Feb 2020 13:20:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 669DA6B0006; Tue, 4 Feb 2020 13:20:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 556EE6B0007; Tue, 4 Feb 2020 13:20:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0220.hostedemail.com [216.40.44.220]) by kanga.kvack.org (Postfix) with ESMTP id 3B8A76B0005 for ; Tue, 4 Feb 2020 13:20:27 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D6E7621F0 for ; Tue, 4 Feb 2020 18:20:26 +0000 (UTC) X-FDA: 76453259652.12.bat17_3e066ba1b6020 X-HE-Tag: bat17_3e066ba1b6020 X-Filterd-Recvd-Size: 5941 Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Tue, 4 Feb 2020 18:20:26 +0000 (UTC) Received: by mail-pl1-f194.google.com with SMTP id p11so7597029plq.10 for ; Tue, 04 Feb 2020 10:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CAMBy3NGAyHNH2wCGCsteiJRgCMQA3d7e+wpMMPzaNM=; b=dBA6JtY8VAIHgTSG/m3Mm694yoeeGq0PpedkAvgfVdygHk+yDxvbEkaI0OZgAruXCd Oqxs/pAIkdyQh3FUG6RW6hx5Jm+8ioqk1rDFVpeB4P7NAkkgWAwIHKgE5toPWVQ/Gfp4 spH3EiYZ+2IrGNIGbKXv45ye3A6lTdm7929uTztEkFX0h/iyZ/JsRt5CDrtU/vfVKq4d gbIZHXJKSkEDYaUeRZlPLXThNErMfFRfj3ZS5FK665oPREjtQwyQaLevKqdqy4HinU68 F7UvQkHg8tQdVE6eajwq41kb0fIzVHYnWkT+AJoHJ1OQFbiJxHHeWYi12IuU9pcbg+4j zxhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CAMBy3NGAyHNH2wCGCsteiJRgCMQA3d7e+wpMMPzaNM=; b=o5A2+YIEanhJ+BpiaPFpnDGthseUbBZ5vXajpiAkXnKoySNEZOLxs79ZW16UPWOCgP QbMGRTKnuKqqsWPzHKy0DOsabuyPzV2UNnbb4w20sXZhBIrXEevHnmlEN3tlWP4hXeH9 INQ4by6YLOaB/iTn+hQmdVebyXVz116EubxhLUlmQ7fyrtU2FhTsa55Pqw7xhADIuLOc u2U/KPtPFGfzlJ9f3UZ3kMW2rSrmlMl7+BhIROdBnOWVdCOdNUPQdPkVKf/csJHYMbkF TZCRkHF3+DmdwncyfT38OXpwRhVfB47VMVLe+I/cyCJJf0ynKcw1t8NkqWZnxD8ZDPCP mXUQ== X-Gm-Message-State: APjAAAV5KZEOk0HFiDiyvmVQPJ+S69EMhk5Coq87Sr65XWl9iGNUdpk7 uk6ZJhJI3oYT4mRVrWIu0348sw== X-Google-Smtp-Source: APXvYqwRjsxFHkomjw16464hTqweh60BpZMJ6xeDoW9lFDkzNpbofpmThIZb3diiY9PJQguYwiSX3A== X-Received: by 2002:a17:90a:cb11:: with SMTP id z17mr468603pjt.122.1580840424859; Tue, 04 Feb 2020 10:20:24 -0800 (PST) Received: from gnomeregan.cam.corp.google.com ([2620:15c:6:14:50b7:ffca:29c4:6488]) by smtp.googlemail.com with ESMTPSA id f127sm25578589pfa.112.2020.02.04.10.20.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Feb 2020 10:20:24 -0800 (PST) Subject: Re: [PATCH RFC 10/10] nvdimm/e820: add multiple namespaces support To: Dan Williams Cc: Joao Martins , linux-nvdimm , Vishal Verma , Dave Jiang , Ira Weiny , Alex Williamson , Cornelia Huck , KVM list , Andrew Morton , Linux MM , Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , X86 ML , Liran Alon , Nikita Leshenko , Boris Ostrovsky , Matthew Wilcox , Konrad Rzeszutek Wilk References: <20200110190313.17144-1-joao.m.martins@oracle.com> <20200110190313.17144-11-joao.m.martins@oracle.com> From: Barret Rhoden Message-ID: Date: Tue, 4 Feb 2020 13:20:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Hi - On 2/4/20 11:44 AM, Dan Williams wrote: > On Tue, Feb 4, 2020 at 7:30 AM Barret Rhoden wrote: >> >> Hi - >> >> On 1/10/20 2:03 PM, Joao Martins wrote: >>> User can define regions with 'memmap=size!offset' which in turn >>> creates PMEM legacy devices. But because it is a label-less >>> NVDIMM device we only have one namespace for the whole device. >>> >>> Add support for multiple namespaces by adding ndctl control >>> support, and exposing a minimal set of features: >>> (ND_CMD_GET_CONFIG_SIZE, ND_CMD_GET_CONFIG_DATA, >>> ND_CMD_SET_CONFIG_DATA) alongside NDD_ALIASING because we can >>> store labels. >> >> FWIW, I like this a lot. If we move away from using memmap in favor of >> efi_fake_mem, ideally we'd have the same support for full-fledged >> pmem/dax regions and namespaces that this patch brings. > > No, efi_fake_mem only supports creating dax-regions. What's the use > case that can't be satisfied by just specifying multiple memmap= > ranges? I'd like to be able to create and destroy dax regions on the fly. In particular, I want to run guest VMs using the dax files for guest memory, but I don't know at boot time how many VMs I'll have, or what their sizes are. Ideally, I'd have separate files for each VM, instead of a single /dev/dax. I currently do this with fs-dax with one big memmap region (ext4 on /dev/pmem0), and I use the file system to handle the creation/destruction/resizing and metadata management. But since fs-dax won't work with device pass-through, I started looking at dev-dax, with the expectation that I'd need some software to manage the memory (i.e. allocation). That led me to ndctl, which seems to need namespace labels to have the level of control I was looking for. Thanks, Barret