Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5420821ybl; Tue, 4 Feb 2020 13:45:02 -0800 (PST) X-Google-Smtp-Source: APXvYqy8EB9DZCPHhzIvOp3qLmqPe/JePCyVKO7zVndkBdXkNjzzdYjqniC0oSgoCOxFLxv9nwrF X-Received: by 2002:aca:ad11:: with SMTP id w17mr742992oie.85.1580852702166; Tue, 04 Feb 2020 13:45:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580852702; cv=none; d=google.com; s=arc-20160816; b=tYqHLbFR6D+dDd2wd0hjvuxMyaKTRJf7Pf50m2ypZiA0rgspqKHzwPRiQM5oUr4c/C B1zw4wpQYLEjqLKt8D8fkOeqgkXUNN5HZYZYrS/KoBcAbRc0EP/grxtQokZRLTfxLGbF 4oz9v5mkw3pzZ1jOZgNwFQfk1gDWbIOZBIsi0w8KPoSVNWkWCuoKH0v6MFyemIW8It0d UIzM81GhFoF59D4kC1AsyVxF/kQPPasSxHdRyi+SunpINQDgQx8QsXhkE8EI8asYxwB0 4V3fhmF9qY5eZN87q3otf8XuJf4FF5Bn9wD2Ih2lZvs8lC00s3C1Ne7U3TsGV7eC+dtk lsmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=h4sd+ZATda3xgd2Cabp+ey5GfoagpPrGA3dH0HD9uD4=; b=eNurUwd/mKJLIIdSP89bPlIQz5bl0SSafOL4YquIpxjyP6yVn/JVj+mEU5maI08BRJ GwVyskE67yeVrW8WYMdqkEG8v+n1004Og4d5KiF1aS/IPaLUnYSvWSc5QexD6PM+fYUq ArVgEJy9Lld2mZAS21AFWVM6RGdV2K0Ck3ETLDvL1jgKjVKrMsM9i6cU5UxHzguBnSlC zSl1OQS2hfuBHl5/sVFASpxXAb1K8K+LooTj7i6zz5ASdF5AzQHzv/g/idS5bGW4uu5L ZWm1oig/NmifADcEm/pjhzkvpxCtrXwjIO325gljLtK2k3Kj37vOTC0yFiqLeuxAUau/ eG1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=om0IxymU; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y205si11531077oig.137.2020.02.04.13.44.49; Tue, 04 Feb 2020 13:45:02 -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=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=om0IxymU; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727480AbgBDVnt (ORCPT + 99 others); Tue, 4 Feb 2020 16:43:49 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:40509 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727389AbgBDVnt (ORCPT ); Tue, 4 Feb 2020 16:43:49 -0500 Received: by mail-ot1-f68.google.com with SMTP id i6so18663868otr.7 for ; Tue, 04 Feb 2020 13:43:49 -0800 (PST) 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=h4sd+ZATda3xgd2Cabp+ey5GfoagpPrGA3dH0HD9uD4=; b=om0IxymUwPkvWyb01X9tGRJ2/DQx9Zp+ONzq9K7omFBcxtLbIr+tzBJigBSQmHj8ji gecf238XvqhNWCuCqz2KAnrN3hTNL031wGf8u0cF3krNJjO2TYR57Dh5Iw9/Q50LRnkl QuE9a58jgymDElHyDs9NcX4/me9PQ561Fcz/F9UKFm3td3WJmgu2NBt2/IM50iZA2jYR ynmSHN6PcWaa83ih4P3Dpic9Y+SrcIIVXw5jNyh5WQPZRLL9gyDTVPllEJgs5elyQq2f f0vXXrc67OfZVvCrI/PryDxZ6ot5Kg/9J5OGoqR0kSXlTMTH4V1nKwTKuhVR/rFzH6xV XGow== 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=h4sd+ZATda3xgd2Cabp+ey5GfoagpPrGA3dH0HD9uD4=; b=baYSCf39LY11J8m2WUAa2u5d+pTQiRqlatmRN778z5GxKe3aO5DjBCgOMjASCp8v/v JYrg/ogJZaT60blefXr1kDYp86AbZIMvRgSoVAXWGBNff/ENEIgW6ZFIJTB6RLRRUR8S CCf3ZFyydmdyYj1NZeZoWijKxpGAC2pGDu0zcPCadqnxSP0haZQO9gy/ODkE9X9DNINd L8lh/Zvyal7psf/Vpd2TUjXijIhr8FItrpTkaIIeT9ZYVUjHsk6q9e8xSe1ee0/lLzaK y3l3hsKNGFVEY2bn637AAUkkYknwN4Kx2bu+DjJhSSy5np8cJ8W96g1qS4talFzeniX7 dJ3A== X-Gm-Message-State: APjAAAVeqJgp9GIxt3eoKIJtnvLHGrXhp3VD2qDoeQN8SKekolzc1RBP xVbem65XUC0nhr84ZY5Nenc1uFbNv05XLcnN6Jv2VA== X-Received: by 2002:a9d:4e99:: with SMTP id v25mr24222626otk.363.1580852628908; Tue, 04 Feb 2020 13:43:48 -0800 (PST) MIME-Version: 1.0 References: <20200110190313.17144-1-joao.m.martins@oracle.com> <20200110190313.17144-11-joao.m.martins@oracle.com> In-Reply-To: From: Dan Williams Date: Tue, 4 Feb 2020 13:43:37 -0800 Message-ID: Subject: Re: [PATCH RFC 10/10] nvdimm/e820: add multiple namespaces support To: Barret Rhoden 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 4, 2020 at 10:20 AM Barret Rhoden wrote: > > 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. Ah, got it, you only ended up at wanting namespace labels because there was no other way to carve up device-dax. That's changing as part of the efi_fake_mem= enabling and I have a patch set in the works to allow discontiguous sub-divisions of a device-dax range. Note that is this branch rebases frequently: https://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git/log/?h=libnvdimm-pending > > Thanks, > > Barret >