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=-5.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 B8D8AC3524B for ; Tue, 4 Feb 2020 21:43:53 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 80C3A21744 for ; Tue, 4 Feb 2020 21:43:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="om0IxymU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 80C3A21744 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id B484B1007B1F7; Tue, 4 Feb 2020 13:47:10 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::341; helo=mail-ot1-x341.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D694E1007B1F1 for ; Tue, 4 Feb 2020 13:47:07 -0800 (PST) Received: by mail-ot1-x341.google.com with SMTP id 77so18670812oty.6 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=S2xw/dpUvvOlecv2NV2nd5EtB0svmGjBJ4D+sDv5Ibjl/sqWAWZRz9t10OTICxmdvx kGbtGVQKkcuE/ybLzLXqRW3nQYLThLBIUun4/heDYxnJq/6qOm4od5r4uDqgJuIAs6TC oR8R9J3nTTNKx/GunrpbfPmmWn4yHGODPBf67Fu/fFknnRhvmYTA5KXHtMKa96iavEWS lsSxTTS7wWxhXAZheZYqkB840oCHQJBTLXO3ui0KjMc/oYWon3AQW3rccHVjLeoaj3Tp Qnl/w1o20rH+4jyNNYuQfTdyy/TrbiqjBHuCIT/iSoaY92XOromA74yWlyvaxOP9OuSP XSqA== X-Gm-Message-State: APjAAAU+04Od2vxh1W5fia+dNfjoCkDrN20UljK9MJFd5ODxug8bKrNV 2qoTGeSMQsghi/5gXXja8QcPzamv7POtoazYj/pwAQ== X-Google-Smtp-Source: APXvYqyzRa/EgbcHWU5oWYs3EwkkIOeOuYIq70nRVJ+YY8OVe8Drtam8ArdPOslMqNhBe4zCRcUBk63gv56UchKAyW4= 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 Message-ID-Hash: RHT43YYBUL74YDJ33WQQPWL4LBAM36MR X-Message-ID-Hash: RHT43YYBUL74YDJ33WQQPWL4LBAM36MR X-MailFrom: dan.j.williams@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Joao Martins , linux-nvdimm , 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 X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 > _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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=-5.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 C5F6FC3524D for ; Tue, 4 Feb 2020 21:43:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 975012084E for ; Tue, 4 Feb 2020 21:43:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="om0IxymU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727500AbgBDVnt (ORCPT ); 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-Google-Smtp-Source: APXvYqyzRa/EgbcHWU5oWYs3EwkkIOeOuYIq70nRVJ+YY8OVe8Drtam8ArdPOslMqNhBe4zCRcUBk63gv56UchKAyW4= 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 > 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=-5.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 3A4E1C35247 for ; Tue, 4 Feb 2020 21:43:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E6D552084E for ; Tue, 4 Feb 2020 21:43:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="om0IxymU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E6D552084E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 954CE6B0006; Tue, 4 Feb 2020 16:43:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 903586B0007; Tue, 4 Feb 2020 16:43:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8232F6B0008; Tue, 4 Feb 2020 16:43:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id 67D266B0006 for ; Tue, 4 Feb 2020 16:43:51 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 24BCB824C742 for ; Tue, 4 Feb 2020 21:43:51 +0000 (UTC) X-FDA: 76453772262.07.balls79_5bb13aa4ba128 X-HE-Tag: balls79_5bb13aa4ba128 X-Filterd-Recvd-Size: 5978 Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Tue, 4 Feb 2020 21:43:49 +0000 (UTC) Received: by mail-ot1-f68.google.com with SMTP id 59so18654960otp.12 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=b1tk3ZEzNSZfN4xO/qpASXWyN+wnTDr362C6D3qhH5m+p0hDAsC4HPUdH77hTB+PM5 A8YpRo/1It2fFMLXvMPv23dmklmRvEQqjDpvybiKue5BESyFCVLCFXa984rBUqKBGpF/ zCL0Qn52Gr8ZQzUDY7O8gHrQu4PRFCx9zxM93b1UHmG3NheO7hRORzrgYPmhSfRzCeMI 2tfPWbTIkCKdFatN/0k66TULklWfbLl4vQCmeoUTxDjKSl2Byp4rjEGVfivDcBu6m2Wz Kmaa2BGF+XvtReVM4s9P9aqKR2ceMOx4vQvucifivFO88EjQp5VGLZwodQorS2QAmBo4 6rHA== X-Gm-Message-State: APjAAAWJ11Mykw8pFyMmMMiEuYVBMITJMBT8W4rXRCJ0ZpV5pGkd1iKK MJMdHDon44NJjtMv5ZShGz4T+qvWO7zZexpoBsrkPg== X-Google-Smtp-Source: APXvYqyzRa/EgbcHWU5oWYs3EwkkIOeOuYIq70nRVJ+YY8OVe8Drtam8ArdPOslMqNhBe4zCRcUBk63gv56UchKAyW4= 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>