[PATCH v2] nfit: add Hyper-V NVDIMM DSM command set to white list

[Dexuan Cui]

> From: Dan Williams <dan.j.williams at intel.com>
> Sent: Friday, February 1, 2019 5:29 PM
> > ...
> > The "size" and "mode" still don't look right, but the improvement is that
> > now I can see a good descriptive "name", which I suppose is retrieved
> > from Hyper-V.
> 
> Mode is right, there is no way for Hyper-V to create Linux fsdax mode
> namespaces it requires some setup using variables only Linux knows.
> Can you send the output of:
> 
> ndctl read-labels -j all

The output is from a kernel built with the libnvdimm-pending branch plus
the one-line patch (label->flags &= ~NSLABEL_FLAG_LOCAL) in 
init_active_labels():

root at decui-gen2-u1904:~# ndctl read-labels -j all
[
  {
    "dev":"nmem1",
    "index":[
      {
        "signature":"NAMESPACE_INDEX",
        "major":1,
        "minor":2,
        "labelsize":256,
        "seq":1,
        "nslot":2
      },
      {
        "signature":"NAMESPACE_INDEX",
        "major":1,
        "minor":2,
        "labelsize":256,
        "seq":2,
        "nslot":2
      }
    ],
    "label":[
      {
        "uuid":"c258aaab-f72b-e546-bfa5-be5e07761dbc",
        "name":"Microsoft Hyper-V NVDIMM 1 Label",
        "slot":0,
        "position":0,
        "nlabel":1,
        "isetcookie":708891662257476870,
        "lbasize":0,
        "dpa":0,
        "rawsize":137438953472,
        "type_guid":"79d3f066-f3b4-7440-ac43-0d3318b78cdb",
        "abstraction_guid":"00000000-0000-0000-0000-000000000000"
      }
    ]
  },
  {
    "dev":"nmem0",
    "index":[
      {
        "signature":"NAMESPACE_INDEX",
        "major":1,
        "minor":2,
        "labelsize":256,
        "seq":1,
        "nslot":2
      },
      {
        "signature":"NAMESPACE_INDEX",
        "major":1,
        "minor":2,
        "labelsize":256,
        "seq":2,
        "nslot":2
      }
    ],
    "label":[
      {
        "uuid":"9f0497a7-4453-7c40-ad35-21a791e00345",
        "name":"Microsoft Hyper-V NVDIMM 0 Label",
        "slot":0,
        "position":0,
        "nlabel":1,
        "isetcookie":708891619307803909,
        "lbasize":0,
        "dpa":0,
        "rawsize":34359738368,
        "type_guid":"79d3f066-f3b4-7440-ac43-0d3318b78cdb",
        "abstraction_guid":"00000000-0000-0000-0000-000000000000"
      }
    ]
  }
]
read 2 nmems

> > With Ubuntu 19.04 (4.18.0-11-generic), I get this:
> > (Note: the "mode" and "size" are correct. The "uuid" is different from
> > the above "9f0497a7-4453-7c40-ad35-21a791e00345" -- this is weird.)
> >
> > root at decui-gen2-u1904:~# ndctl list
> > [
> >   {
> >     "dev":"namespace1.0",
> >     "mode":"raw",
> >     "size":137438953472,
> >     "blockdev":"pmem1"
> >   },
> >   {
> >     "dev":"namespace0.0",
> >     "mode":"fsdax",
> >     "map":"dev",
> >     "size":33820770304,
> >     "uuid":"35018886-397e-4fe7-a348-0a4d16eec44d",
> >     "blockdev":"pmem0"
> >   }
> > ]
> 
> This is because the Ubuntu kernel has the bug that causes _LSR to fail
> so Linux falls back to a namespace defined by the region boundary. On
> that namespace there is an "fsdax" info block located at the region
> base +4K. That info block is tagged with the uuid of
> "35018886-397e-4fe7-a348-0a4d16eec44d".
Thanks for the explanation!
 
> > I'm trying to find out the correct solution. I apprecite your insights!
> 
> It's a mess. First we need to figure out whether the label is actually
> specifying a size of zero, or there is some other bug.
I agree.
 
> However, the next problem is going to be adding "fsdax" mode support
> on top of the read-only defined namespaces. The ndctl reconfiguration
> flow:
> 
>    ndctl create-namespace -e namespace0.0 -m fsdax -f

> 
> ...will likely fail because deleting the previous namespace in the
> labels is part of that flow. It's always that labels are writable.
> 
> Honestly, the quickest path to something functional for Linux is to
> simply delete the _LSR support and use raw mode defined namespaces.
> Why have labels if they are read-only and the region is sufficient for
> defining boundaries?

Just now Hyper-V team confirmed _LSW is not supported.

But with Ubuntu 19.04 kernel (4.18.0-11-generic), I'm able to run the commands
without any issue:

root at decui-gen2-u1904:~# ndctl list
[
  {
    "dev":"namespace1.0",
    "mode":"raw",
    "size":137438953472,
    "blockdev":"pmem1"
  },
  {
    "dev":"namespace0.0",
    "mode":"fsdax",
    "map":"dev",
    "size":33820770304,
    "uuid":"35018886-397e-4fe7-a348-0a4d16eec44d",
    "blockdev":"pmem0"
  }
]

root at decui-gen2-u1904:~# ndctl destroy-namespace "namespace0.0"
  Error: namespace0.0 is active, specify --force for re-configuration

error destroying namespaces: Device or resource busy
destroyed 0 namespaces

root at decui-gen2-u1904:~# ndctl destroy-namespace "namespace0.0" --force
destroyed 1 namespace

root at decui-gen2-u1904:~# ndctl list
[
  {
    "dev":"namespace1.0",
    "mode":"raw",
    "size":137438953472,
    "blockdev":"pmem1"
  }
]

root at decui-gen2-u1904:~# ndctl create-namespace -e namespace0.0 -m fsdax -f
{
  "dev":"namespace0.0",
  "mode":"fsdax",
  "map":"dev",
  "size":"31.50 GiB (33.82 GB)",
  "uuid":"9e4e819b-e2eb-4796-8f9e-15f96f63b5c2",
  "sector_size":512,
  "blockdev":"pmem0",
  "numa_node":1
}

root at decui-gen2-u1904:~# ndctl list
[
  {
    "dev":"namespace1.0",
    "mode":"raw",
    "size":137438953472,
    "blockdev":"pmem1"
  },
  {
    "dev":"namespace0.0",
    "mode":"fsdax",
    "map":"dev",
    "size":33820770304,
    "uuid":"9e4e819b-e2eb-4796-8f9e-15f96f63b5c2",
    "blockdev":"pmem0"
  }
]


The above commands can also run fine with an upstream kernel that
doesn't have 
11189c1089da ("acpi/nfit: Fix command-supported detection")
or
1194c4133195 ("nfit: Add Hyper-V NVDIMM DSM command set to white list")

Thanks
-- Dexuan