Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5251763ybl; Tue, 4 Feb 2020 10:22:37 -0800 (PST) X-Google-Smtp-Source: APXvYqzhra3Gz2gApeS8HI0cHoEwMow9pWNI8BX8jnFhln5kDa+qyop8ZYfbjguZAhQ/0wK+bPWc X-Received: by 2002:aca:2407:: with SMTP id n7mr250487oic.14.1580840557285; Tue, 04 Feb 2020 10:22:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580840557; cv=none; d=google.com; s=arc-20160816; b=oIM7ZaEivmXhndIF5z/4wf/Wiyu3X1pzNfqQmNL3SjK5aRIs4/cMoetXy4Lt1dcjd2 BH2VMfWnmfz+wmM+514vAAPVKR7Kpy0fCFddrGE60IJq+8fUFaD12qyIqwH7ALHZac5w Azq/oZebtyQOFKpLDTmWVBKXokR7GgibVvYgqhehQ8DJsUpSBdAM9y6cDu+0FE1UKqbx Mb4fEuNwt9N31rqvko1zqW2QjHpOl1DOnPXx6L/ryJRZZXgMU/UhLiXFczJDjdzxxDTa SurX/8eMNxvumCpNqbw+zT936ugOzrC8okY+8cpQWZ1V6oTxB3rjKczR6o3tanmEkmY4 beMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=CAMBy3NGAyHNH2wCGCsteiJRgCMQA3d7e+wpMMPzaNM=; b=tylIreoEvgipX5SWX+ITtqN6NEfnGsCNQ1ukotTJq6D/Xt9v7cKQsVSdXHdI3z2Z1S DPlr8UjJcl0lTS4JKWK4wenB30+9RdKeEn0ccNm0eWN2A/lUSNCnatg/sLK860m+Th70 6zPr7jQQpm7dG9rmEgeynd7eJpng9qwTv/HSBkHnx0WK6CkFVLNWZx2txffEAH/ASwpm waY+Vl09mXQfEDve4y6PZyfsZwwWQkC74rcC6LJuxTA6W08FcSmALwhTf8i6xNTRijJF RZholAbVDBr2ACS1Xt5WfIVStq1RyGLG8sAk/MOuph9Xj7PZOjhEv2qSumsplh6jVm0L L6qg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dBA6JtY8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m4si12314633otn.281.2020.02.04.10.22.24; Tue, 04 Feb 2020 10:22:37 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dBA6JtY8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727479AbgBDSU1 (ORCPT + 99 others); Tue, 4 Feb 2020 13:20:27 -0500 Received: from mail-pl1-f193.google.com ([209.85.214.193]:44665 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727442AbgBDSU1 (ORCPT ); Tue, 4 Feb 2020 13:20:27 -0500 Received: by mail-pl1-f193.google.com with SMTP id d9so7590531plo.11 for ; Tue, 04 Feb 2020 10:20:25 -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=HOGUONZxh3dJ7YsOXD103zvzVxFSlQ6QxMX45FWnb+h3WOpggl7k8b1v1P9CjqdT+y c/GmPJm6K/pTwYA860tqS5lLGRY/CwV34Uzaxy+Qg18TFzKmdDT4kOP9AjdQ6pevzcsK 1F5gb9GoPL1L6abfP8kifH3XM8QSHcADj3NstlHtS7/vplUcqVcxdZMyxl1rxo5Cqprw sKMggLb822Zp6J90jNUp5SN1otMocb8lPSEbEKQ2vQC+Zgp9kRhVzJHIvvrhGCLdIKiy 4tnby5MDV0NYbqvot4/ydHrtu1Czsqd32Ifzko9KBzbtreOGTgvUmksjG/JAQJdwtSXZ QuSA== X-Gm-Message-State: APjAAAVHfrgQE2zmy86LqPQCyMBVwtSke9Sbu4dcLjqQtbBDEsdjBHTU fIt6FY8o01cca6r7XRxWkrJUWg== 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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