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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 78718C3F68F for ; Tue, 4 Feb 2020 16:44:48 +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 4E772217BA for ; Tue, 4 Feb 2020 16:44:48 +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="E8BMVd2O" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E772217BA 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 884D110FC339B; Tue, 4 Feb 2020 08:48:05 -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 7571510FC3398 for ; Tue, 4 Feb 2020 08:48:02 -0800 (PST) Received: by mail-ot1-x341.google.com with SMTP id p8so17668836oth.10 for ; Tue, 04 Feb 2020 08:44:44 -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=txCJX4Ne8ohW4iJOJEvhQaXEi/CwoZWs9QB4Yj1b5nw=; b=E8BMVd2Oq2XNQz1eagY0Y+rTL0R1OArk+RNjkxQq4QR/Bf7gXbTtfxyrQDEykMnIHR ZIYTJAG4piDuOptEAgoIFgtwCU06/9y9sKaoiLmmkpV84rsQOEQ/NAg0IN93tOFX9QzO /PnPme6X6LhS85N6jcrz5EqfY+xiY2ggFBHaY+rtueU8D1S8u/NNple1nQKALIFSvNVW PaThBkXTx0caPjS/4ue/jNpLbD60+T30X9Gu1bSWJUt80x0TJ5ZoL0cTEE1238+Gvjew zoVvC54nNhjGAmzxiEtx5R533wm4iuWhq18ZyJKuk10dgIyMAXqY1KynN1wgW6/XdFhm R9jw== 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=txCJX4Ne8ohW4iJOJEvhQaXEi/CwoZWs9QB4Yj1b5nw=; b=q4qM0JtR9Kvi2DkvGthiAapv1sfJBWrs2EmzYzWD5WJJVm7D6aOCEzMhOtgRIrBs7a Ov8cpLkuRq/PL7GE1JweduuXvqctlGKek9qxbuRpdBzTHThUF3zXZU9i4TPqClNmcvM+ 4NQpEmZ3hAe4BfqRSJBbj1L3hv4TKF/7HXRvYFkn54RU4appQysYqrJc+8WR+Mg7xdjP w3i0yrlZMaNLjDCkVa/HVPstryEkQT3+wVUtni4ZDaRlGxgAzyardF1gX3mNU5XdoLkG fuwMIXQsnIl7LOZN8zA3SdtAD/GIP72vqqT3C341xPTLupdTcIuLelOgdGqU7RkNw/SN KAgA== X-Gm-Message-State: APjAAAUG1OqnI/YGTbIi0zTIPdzTjJ1JdQ8QTZ3ghXF1enNM/wMvfGhS QGtSmLnY808sKITVDJoXBE+4Ni2qg9DKWpuK4XIkXw== X-Google-Smtp-Source: APXvYqzgn5XWbVJRcw05AyZXj+WSrtxUuUc1VbpFIxK+pSeYmXs4lh9OAJSchu3D7rwCd4p8faMkZHZi8Bn21THy1dU= X-Received: by 2002:a9d:7852:: with SMTP id c18mr21603447otm.247.1580834683627; Tue, 04 Feb 2020 08:44:43 -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 08:44:31 -0800 Message-ID: Subject: Re: [PATCH RFC 10/10] nvdimm/e820: add multiple namespaces support To: Barret Rhoden Message-ID-Hash: XWVH62JLXYPIWB24CABUGIXLL3RUTPEA X-Message-ID-Hash: XWVH62JLXYPIWB24CABUGIXLL3RUTPEA 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 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? _______________________________________________ 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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E95A6C35247 for ; Tue, 4 Feb 2020 16:44:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C18BF2082E for ; Tue, 4 Feb 2020 16:44:45 +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="E8BMVd2O" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727378AbgBDQop (ORCPT ); Tue, 4 Feb 2020 11:44:45 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:35027 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727330AbgBDQoo (ORCPT ); Tue, 4 Feb 2020 11:44:44 -0500 Received: by mail-ot1-f68.google.com with SMTP id r16so17751361otd.2 for ; Tue, 04 Feb 2020 08:44:44 -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=txCJX4Ne8ohW4iJOJEvhQaXEi/CwoZWs9QB4Yj1b5nw=; b=E8BMVd2Oq2XNQz1eagY0Y+rTL0R1OArk+RNjkxQq4QR/Bf7gXbTtfxyrQDEykMnIHR ZIYTJAG4piDuOptEAgoIFgtwCU06/9y9sKaoiLmmkpV84rsQOEQ/NAg0IN93tOFX9QzO /PnPme6X6LhS85N6jcrz5EqfY+xiY2ggFBHaY+rtueU8D1S8u/NNple1nQKALIFSvNVW PaThBkXTx0caPjS/4ue/jNpLbD60+T30X9Gu1bSWJUt80x0TJ5ZoL0cTEE1238+Gvjew zoVvC54nNhjGAmzxiEtx5R533wm4iuWhq18ZyJKuk10dgIyMAXqY1KynN1wgW6/XdFhm R9jw== 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=txCJX4Ne8ohW4iJOJEvhQaXEi/CwoZWs9QB4Yj1b5nw=; b=Qa1hQudhXG+5G2q8syUfYga+Q1Eki/3e+/jm1xla1nnE23MVEG/ZxfDtbkNtFBIgXw YEkcFj68tZNb7wuM3dLaltg7DIDv0sKfJrXYrJAvRcw1rsVyW8ysTRjGxXANdSaNmgiY yNsqDs8H4vBsz2f+BrxryueIKx3ew3lEG9zDY7cDeYyMcrZNERwxU5ol72xY/hgekpam LSY+gEZenM1bf10nOdQo2+7ZZUaCiQJd2nWSVIwxZtLkBPZ8NzhS6/+vchIUsX7yDcdh 8+z65llu3eb44BKmUaHxSjyxg9u/yVXn+aXXvXWD0+I8qVmstgz387I6sf14rwm97CIk p3pw== X-Gm-Message-State: APjAAAULP2XyTcZaQ5VmqwevF5DNYCBg0Jrt8gY6tFrdDNthD0EJgcS0 IA73GrZlPMi22Il2jyobsK3/nTvtSUvZwtlgSM1lPg== X-Google-Smtp-Source: APXvYqzgn5XWbVJRcw05AyZXj+WSrtxUuUc1VbpFIxK+pSeYmXs4lh9OAJSchu3D7rwCd4p8faMkZHZi8Bn21THy1dU= X-Received: by 2002:a9d:7852:: with SMTP id c18mr21603447otm.247.1580834683627; Tue, 04 Feb 2020 08:44:43 -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 08:44:31 -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 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? 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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 A4796C3524D for ; Tue, 4 Feb 2020 16:44:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 699C021744 for ; Tue, 4 Feb 2020 16:44:46 +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="E8BMVd2O" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 699C021744 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 DBFDA6B0003; Tue, 4 Feb 2020 11:44:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D70776B0006; Tue, 4 Feb 2020 11:44:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C61C16B0007; Tue, 4 Feb 2020 11:44:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0108.hostedemail.com [216.40.44.108]) by kanga.kvack.org (Postfix) with ESMTP id AB7F06B0003 for ; Tue, 4 Feb 2020 11:44:45 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4E96F181AC212 for ; Tue, 4 Feb 2020 16:44:45 +0000 (UTC) X-FDA: 76453018530.24.flame33_639cb9371e024 X-HE-Tag: flame33_639cb9371e024 X-Filterd-Recvd-Size: 4426 Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Tue, 4 Feb 2020 16:44:44 +0000 (UTC) Received: by mail-ot1-f66.google.com with SMTP id b18so17756520otp.0 for ; Tue, 04 Feb 2020 08:44:44 -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=txCJX4Ne8ohW4iJOJEvhQaXEi/CwoZWs9QB4Yj1b5nw=; b=E8BMVd2Oq2XNQz1eagY0Y+rTL0R1OArk+RNjkxQq4QR/Bf7gXbTtfxyrQDEykMnIHR ZIYTJAG4piDuOptEAgoIFgtwCU06/9y9sKaoiLmmkpV84rsQOEQ/NAg0IN93tOFX9QzO /PnPme6X6LhS85N6jcrz5EqfY+xiY2ggFBHaY+rtueU8D1S8u/NNple1nQKALIFSvNVW PaThBkXTx0caPjS/4ue/jNpLbD60+T30X9Gu1bSWJUt80x0TJ5ZoL0cTEE1238+Gvjew zoVvC54nNhjGAmzxiEtx5R533wm4iuWhq18ZyJKuk10dgIyMAXqY1KynN1wgW6/XdFhm R9jw== 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=txCJX4Ne8ohW4iJOJEvhQaXEi/CwoZWs9QB4Yj1b5nw=; b=uXWD9e2Vfl9pzdE9gWW863wwlNDcrB2Un8cYaR2TBGri6GiRe1LkKqt4fe8nz8J8NC zGg9XICivr8mMgQsXnWAgbq2qd7BRxXYjrblQir9Qycw6zQX2hJ9Qotfw5On9u1dzfXR L5Ra6tzjZuMVdo8uu5VMpA2201RC6rmOuk99KtZfLjsM25Gm9vznyOShTxmRZHhbKGTt XmqHyHT4oxpfCjdxwTgOANm46murEj/Km+95onITca+VLFSlLf+zMO4gQVlIwE0cRjG9 63A1OaLDboHcm8sJjhes/Tle6CJdZbbxFwgUthVxQCyWTqg4Tai4YK+f++y4W2VQmP4J KtZQ== X-Gm-Message-State: APjAAAVHBFj3GhiZAM5Pc3lZH30I6QPYKJeZ8bLeFeXBWzVYx8sUExbb oQUvO1UX+HChaJUQ/eXPtNiKQEQqSYZxgzG79Q/9LA== X-Google-Smtp-Source: APXvYqzgn5XWbVJRcw05AyZXj+WSrtxUuUc1VbpFIxK+pSeYmXs4lh9OAJSchu3D7rwCd4p8faMkZHZi8Bn21THy1dU= X-Received: by 2002:a9d:7852:: with SMTP id c18mr21603447otm.247.1580834683627; Tue, 04 Feb 2020 08:44:43 -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 08:44:31 -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" 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: 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?