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 2638AC35247 for ; Tue, 4 Feb 2020 16:44:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ED99921744 for ; Tue, 4 Feb 2020 16:44:47 +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 S1727358AbgBDQop (ORCPT ); Tue, 4 Feb 2020 11:44:45 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:39190 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727348AbgBDQoo (ORCPT ); Tue, 4 Feb 2020 11:44:44 -0500 Received: by mail-ot1-f67.google.com with SMTP id 77so17715649oty.6 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=Z791D5Rjh+s52ay1VolhouDzmp0ugoV4XBA3mcYmju4h8edgxanhBIHSw9LjAvQ/GS MECqmFvoc4LYSRGCoEVMeS6GyexQRRB5ZYW1b2l4wTxFOHH3PydgDVKMZLxuFkQ+QQHG xQ6TzGX5wuIUJdFAtBG6DIxEx16J1+WlHy5u1Yac6Wgd5GrdR3Hy48Ggdy18WxP58oOd hK0AJIlQ7AhKGSFkQIKkyk5Kzd9dOErPXOoekrRQfyjgp78enWqUp3HoTOP7pSj9us6Q YD5UjlTJR4M5bdYReXSnXBx9doMLKKfyKbSQbTpBVQ+s4qrwYiPtxG8WQaZhi1gYDuWL 17aw== X-Gm-Message-State: APjAAAVD/Ct6nYQU7Jqc5gLlwUuqacJG+hVSEdf6cWlLaD8i6XokthbU ee0EAFKZVisnxVvGfS4V/ASw0yNajeVmpec34KsOVQ== 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: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@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?