RE: [PATCH] acpi/nfit: Require opt-in for read-only label configurations
> From: Dan Williams > Sent: Sunday, February 3, 2019 11:29 AM > ... > Recent fixes to command handling enabled Linux to read label > configurations that it could not before. Unfortunately that means that > configurations that were operating in label-less mode will be broken as > the kernel ignores the existing namespace configuration and tries to > honor the new found labels. > > Fortunately this seems limited to a case where Linux can quirk the > behavior and maintain the existing label-less semantics by default. > When the platform does not emit an _LSW method, disable all label access > methods. Provide a 'force_labels' module parameter to allow read-only > label operation. > > Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection") > Reported-by: Dexuan Cui > Signed-off-by: Dan Williams Hi Dan, Thanks for the patch and all the detailed explanation! With this patch, the "fsdax" namespace can be properly detected now! Thanks, -- Dexuan ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
[PATCH] acpi/nfit: Require opt-in for read-only label configurations
Recent fixes to command handling enabled Linux to read label configurations that it could not before. Unfortunately that means that configurations that were operating in label-less mode will be broken as the kernel ignores the existing namespace configuration and tries to honor the new found labels. Fortunately this seems limited to a case where Linux can quirk the behavior and maintain the existing label-less semantics by default. When the platform does not emit an _LSW method, disable all label access methods. Provide a 'force_labels' module parameter to allow read-only label operation. Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection") Reported-by: Dexuan Cui Signed-off-by: Dan Williams --- drivers/acpi/nfit/core.c | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c index 811c399a3a76..5b5e802de7b8 100644 --- a/drivers/acpi/nfit/core.c +++ b/drivers/acpi/nfit/core.c @@ -56,6 +56,10 @@ static bool no_init_ars; module_param(no_init_ars, bool, 0644); MODULE_PARM_DESC(no_init_ars, "Skip ARS run at nfit init time"); +static bool force_labels; +module_param(force_labels, bool, 0444); +MODULE_PARM_DESC(force_labels, "Opt-in to labels despite missing methods"); + LIST_HEAD(acpi_descs); DEFINE_MUTEX(acpi_desc_lock); @@ -1916,6 +1920,19 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc, dev_dbg(dev, "%s: has _LSW\n", dev_name(_dimm->dev)); set_bit(NFIT_MEM_LSW, _mem->flags); } + + /* +* Quirk read-only label configurations to preserve +* access to label-less namespaces by default. +*/ + if (!test_bit(NFIT_MEM_LSW, _mem->flags) + && !force_labels) { + dev_dbg(dev, "%s: No _LSW, disable labels\n", + dev_name(_dimm->dev)); + clear_bit(NFIT_MEM_LSR, _mem->flags); + } else + dev_dbg(dev, "%s: Force enable labels\n", + dev_name(_dimm->dev)); } populate_shutdown_status(nfit_mem); ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
On Sun, Feb 3, 2019 at 10:13 AM Dexuan Cui wrote: > > > From: Dan Williams > > Sent: Sunday, February 3, 2019 9:49 AM > > > ... > > > It looks the namespace created by Ubuntu 19.04 (4.18) is incompatible with > > > the libnvdimm-pending branch + this patch. > > > > This is correct, the configuration switched from label-less by default > > to labeled. > Thanks for the confirmation! > > > > It looks we need to completely disable the label usage for > > NVDIMM_FAMILY_HYPERV > > > due to compability? > > > > It's either going to be a quirk in Linux or a quirk in the Hyper-V > > configuration. I think it's more manageable for Hyper-V to ship a > > "label disable" switch than to try to ship a workaround in Linux. The > > "noblk" quirk in Linux works around the LOCAL bit in the labels. > > However, the namespace mode regression can only be resolved by hiding > > the label capability until the administrator manually switches from > > label-less to labeled operation. > > As I understand, the essence of the issue is: Hyper-V emulates the > label mechanism (i.e. it supports _LSI and LSR), but doesn't do it > right (i.e. it doesn't support _LSW). > > To manage the namespaces, Linux can choose to use label or not. > > If _LSI/_LSR are supported, Linux assumes _LSW is supported as well > and chooses to use label (i.e. the label mode), but since Hyper-V doesn't > support _LSW, Linux fails to change the namespace configuration. No, that's not quite right. The reason Linux does not see the fsdax mode configuration is due to the missing "address abstraction GUID" in the label produced the default Hyper-V configuration. In label-less mode there is no "address abstraction GUID" to validate so it falls back to just using the info-block directly. The _LSW issue is if you wanted to reconfigure a raw namespace to fsdax mode. The current flow tries to delete the label, but that's only for reconfiguration, not the initial boot-up case that is currently failing. The deletion would fail on finding no label-write capability, but to be clear the boot-up case does not perform any writes. > In > Ubuntu 19.04 (4.18), the kernel is not aware of Hyper-V _LSI/_LSR, so > the created namespace is in "label-less" mode, and hence can't be used > with the libnvdimm-pending branch + this patch, unless we add a quirk > in Linux to explicitly not use the label. > > I agree ideally Hyper-V should hide the label capability, and I'll request > Hyper-V team to do that. I hope Hyper-V guys are still able to do that > in time so we won't need a quirk in Linux kernel. After some more thought, the "no regressions" rule means that Linux should ship a quirk for this by default. I think a good heuristic is to disable label support by default if no _LSW method is detected. An opt-in can be specified to accept "read-only" configurations, but that's an exceptional case. I'll send a patch for this. > BTW, I suppose Windows VM should be in "label-less" mode. I expect Windows mandates labeled operation. This label-less concept was something Linux shipped in advance of a specification being ratified and to support early NVDIMMs that don't advertise label space. > Thanks for the help, Dan! Thanks for the quick feedback and testing. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
RE: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
> From: Dan Williams > Sent: Sunday, February 3, 2019 9:49 AM > > ... > > It looks the namespace created by Ubuntu 19.04 (4.18) is incompatible with > > the libnvdimm-pending branch + this patch. > > This is correct, the configuration switched from label-less by default > to labeled. Thanks for the confirmation! > > It looks we need to completely disable the label usage for > NVDIMM_FAMILY_HYPERV > > due to compability? > > It's either going to be a quirk in Linux or a quirk in the Hyper-V > configuration. I think it's more manageable for Hyper-V to ship a > "label disable" switch than to try to ship a workaround in Linux. The > "noblk" quirk in Linux works around the LOCAL bit in the labels. > However, the namespace mode regression can only be resolved by hiding > the label capability until the administrator manually switches from > label-less to labeled operation. As I understand, the essence of the issue is: Hyper-V emulates the label mechanism (i.e. it supports _LSI and LSR), but doesn't do it right (i.e. it doesn't support _LSW). To manage the namespaces, Linux can choose to use label or not. If _LSI/_LSR are supported, Linux assumes _LSW is supported as well and chooses to use label (i.e. the label mode), but since Hyper-V doesn't support _LSW, Linux fails to change the namespace configuration. In Ubuntu 19.04 (4.18), the kernel is not aware of Hyper-V _LSI/_LSR, so the created namespace is in "label-less" mode, and hence can't be used with the libnvdimm-pending branch + this patch, unless we add a quirk in Linux to explicitly not use the label. I agree ideally Hyper-V should hide the label capability, and I'll request Hyper-V team to do that. I hope Hyper-V guys are still able to do that in time so we won't need a quirk in Linux kernel. BTW, I suppose Windows VM should be in "label-less" mode. Thanks for the help, Dan! Thanks, -- Dexuan ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
On Sun, Feb 3, 2019 at 9:22 AM Dexuan Cui wrote: > > > From: Dan Williams > > Sent: Saturday, February 2, 2019 5:13 PM > > ... > > As Dexuan reports the NVDIMM_FAMILY_HYPERV platform is incompatible with > > the existing Linux namespace implementation because it uses > > NSLABEL_FLAG_LOCAL for x1-width PMEM interleave sets. Quirk it as an > > platform / DIMM that does not provide BLK-aperture access. Allow the > > libnvdimm core to assume no potential for aliasing. In case other > > implementations make the same mistake, provide a "noblk" module > > parameter to force-enable the quirk. > > Hi Dan, > Thanks very much for the patch! With it, "ndctl list" can show the below: > > root@decui-gen2-u1904:~/ndctl# ndctl list > [ > { > "dev":"namespace1.0", > "mode":"raw", > "size":137438953472, > "uuid":"c258aaab-f72b-e546-bfa5-be5e07761dbc", > "blockdev":"pmem1", > "name":"Microsoft Hyper-V NVDIMM 1 Label" > }, > { > "dev":"namespace0.0", > "mode":"raw", > "size":34359738368, > "uuid":"9f0497a7-4453-7c40-ad35-21a791e00345", > "blockdev":"pmem0", > "name":"Microsoft Hyper-V NVDIMM 0 Label" > } > ] > > And /dev/pmem0 can appear, but /dev/pmem0p1 can not appear, and the "mode" of > "namespace0.0" is not correct. With the Ubuntu 19.04 4.18 kenel, I get the > below: > > root@decui-gen2-u1904:~/ndctl# ndctl list > [ > { > "dev":"namespace1.0", > "mode":"raw", > "size":137438953472, > "blockdev":"pmem1" > }, > { > "dev":"namespace0.0", > "mode":"fsdax", > "map":"dev", > "size":33820770304, > "uuid":"ef028c4e-2b1f-4bf8-b92a-1109d7a1c914", > "blockdev":"pmem0" > } > ] > and /dev/pmem0p1 can appear. > > It looks the namespace created by Ubuntu 19.04 (4.18) is incompatible with > the libnvdimm-pending branch + this patch. This is correct, the configuration switched from label-less by default to labeled. > It looks we need to completely disable the label usage for > NVDIMM_FAMILY_HYPERV > due to compability? It's either going to be a quirk in Linux or a quirk in the Hyper-V configuration. I think it's more manageable for Hyper-V to ship a "label disable" switch than to try to ship a workaround in Linux. The "noblk" quirk in Linux works around the LOCAL bit in the labels. However, the namespace mode regression can only be resolved by hiding the label capability until the administrator manually switches from label-less to labeled operation. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
RE: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
> From: kbuild test robot > Sent: Sunday, February 3, 2019 6:38 AM > ... > Hi Dan, > > I love your patch! Yet something to improve: > > [auto build test ERROR on linux-nvdimm/libnvdimm-for-next] > [also build test ERROR on v5.0-rc4 next-20190201] > [if your patch is applied to the wrong git tree, please drop us a note to help > improve the system] > ... > config: x86_64-allmodconfig (attached as .config) > compiler: gcc-8 (Debian 8.2.0-14) 8.2.0 > reproduce: > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >drivers/acpi/nfit/core.c: In function 'acpi_nfit_register_dimms': > >> drivers/acpi/nfit/core.c:2003:27: error: 'NVDIMM_FAMILY_HYPERV' > undeclared (first use in this function); did you mean 'NVDIMM_FAMILY_HPE1'? > if (nfit_mem->family == NVDIMM_FAMILY_HYPERV) > ^~~~ > NVDIMM_FAMILY_HPE1 >drivers/acpi/nfit/core.c:2003:27: note: each undeclared identifier is > reported only once for each function it appears in This is a false alarm, too. The patch is only for https://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git/log/?h=libnvdimm-pending where we have the dependant commit: 1194c4133195 ("nfit: Add Hyper-V NVDIMM DSM command set to white list") Thanks, -- Dexuan ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
RE: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
> From: kbuild test robot > Sent: Sunday, February 3, 2019 6:32 AM > To: Dan Williams > Cc: kbuild-...@01.org; linux-nvdimm@lists.01.org; Dexuan Cui > ; linux-ker...@vger.kernel.org > Subject: Re: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM > family > > Hi Dan, > > I love your patch! Yet something to improve: > > [auto build test ERROR on linux-nvdimm/libnvdimm-for-next] > [also build test ERROR on v5.0-rc4 next-20190201] > [if your patch is applied to the wrong git tree, please drop us a note to help > improve the system] > ... > All errors (new ones prefixed by >>): > >drivers/acpi//nfit/core.c: In function 'acpi_nfit_register_dimms': > >> drivers/acpi//nfit/core.c:2003:27: error: 'NVDIMM_FAMILY_HYPERV' > undeclared (first use in this function); did you mean 'NVDIMM_FAMILY_HPE2'? > if (nfit_mem->family == NVDIMM_FAMILY_HYPERV) > ^~~~ > NVDIMM_FAMILY_HPE2 >drivers/acpi//nfit/core.c:2003:27: note: each undeclared identifier is > reported only once for each function it appears in This is a false alarm. The patch is only for https://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git/log/?h=libnvdimm-pending where we have the dependant commid 1194c4133195 ("nfit: Add Hyper-V NVDIMM DSM command set to white list") Thanks, -- Dexuan ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
RE: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
> From: Dan Williams > Sent: Saturday, February 2, 2019 5:13 PM > ... > As Dexuan reports the NVDIMM_FAMILY_HYPERV platform is incompatible with > the existing Linux namespace implementation because it uses > NSLABEL_FLAG_LOCAL for x1-width PMEM interleave sets. Quirk it as an > platform / DIMM that does not provide BLK-aperture access. Allow the > libnvdimm core to assume no potential for aliasing. In case other > implementations make the same mistake, provide a "noblk" module > parameter to force-enable the quirk. Hi Dan, Thanks very much for the patch! With it, "ndctl list" can show the below: root@decui-gen2-u1904:~/ndctl# ndctl list [ { "dev":"namespace1.0", "mode":"raw", "size":137438953472, "uuid":"c258aaab-f72b-e546-bfa5-be5e07761dbc", "blockdev":"pmem1", "name":"Microsoft Hyper-V NVDIMM 1 Label" }, { "dev":"namespace0.0", "mode":"raw", "size":34359738368, "uuid":"9f0497a7-4453-7c40-ad35-21a791e00345", "blockdev":"pmem0", "name":"Microsoft Hyper-V NVDIMM 0 Label" } ] And /dev/pmem0 can appear, but /dev/pmem0p1 can not appear, and the "mode" of "namespace0.0" is not correct. With the Ubuntu 19.04 4.18 kenel, I get the below: root@decui-gen2-u1904:~/ndctl# ndctl list [ { "dev":"namespace1.0", "mode":"raw", "size":137438953472, "blockdev":"pmem1" }, { "dev":"namespace0.0", "mode":"fsdax", "map":"dev", "size":33820770304, "uuid":"ef028c4e-2b1f-4bf8-b92a-1109d7a1c914", "blockdev":"pmem0" } ] and /dev/pmem0p1 can appear. It looks the namespace created by Ubuntu 19.04 (4.18) is incompatible with the libnvdimm-pending branch + this patch. It looks we need to completely disable the label usage for NVDIMM_FAMILY_HYPERV due to compability? Thanks, -- Dexuan ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
Hi Dan, I love your patch! Yet something to improve: [auto build test ERROR on linux-nvdimm/libnvdimm-for-next] [also build test ERROR on v5.0-rc4 next-20190201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dan-Williams/libnvdimm-dimm-Add-a-no-BLK-quirk-based-on-NVDIMM-family/20190203-213444 base: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git libnvdimm-for-next config: x86_64-allmodconfig (attached as .config) compiler: gcc-8 (Debian 8.2.0-14) 8.2.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/acpi/nfit/core.c: In function 'acpi_nfit_register_dimms': >> drivers/acpi/nfit/core.c:2003:27: error: 'NVDIMM_FAMILY_HYPERV' undeclared >> (first use in this function); did you mean 'NVDIMM_FAMILY_HPE1'? if (nfit_mem->family == NVDIMM_FAMILY_HYPERV) ^~~~ NVDIMM_FAMILY_HPE1 drivers/acpi/nfit/core.c:2003:27: note: each undeclared identifier is reported only once for each function it appears in vim +2003 drivers/acpi/nfit/core.c 1944 1945 static int acpi_nfit_register_dimms(struct acpi_nfit_desc *acpi_desc) 1946 { 1947 struct nfit_mem *nfit_mem; 1948 int dimm_count = 0, rc; 1949 struct nvdimm *nvdimm; 1950 1951 list_for_each_entry(nfit_mem, _desc->dimms, list) { 1952 struct acpi_nfit_flush_address *flush; 1953 unsigned long flags = 0, cmd_mask; 1954 struct nfit_memdev *nfit_memdev; 1955 u32 device_handle; 1956 u16 mem_flags; 1957 1958 device_handle = __to_nfit_memdev(nfit_mem)->device_handle; 1959 nvdimm = acpi_nfit_dimm_by_handle(acpi_desc, device_handle); 1960 if (nvdimm) { 1961 dimm_count++; 1962 continue; 1963 } 1964 1965 if (nfit_mem->bdw && nfit_mem->memdev_pmem) 1966 set_bit(NDD_ALIASING, ); 1967 1968 /* collate flags across all memdevs for this dimm */ 1969 list_for_each_entry(nfit_memdev, _desc->memdevs, list) { 1970 struct acpi_nfit_memory_map *dimm_memdev; 1971 1972 dimm_memdev = __to_nfit_memdev(nfit_mem); 1973 if (dimm_memdev->device_handle 1974 != nfit_memdev->memdev->device_handle) 1975 continue; 1976 dimm_memdev->flags |= nfit_memdev->memdev->flags; 1977 } 1978 1979 mem_flags = __to_nfit_memdev(nfit_mem)->flags; 1980 if (mem_flags & ACPI_NFIT_MEM_NOT_ARMED) 1981 set_bit(NDD_UNARMED, ); 1982 1983 rc = acpi_nfit_add_dimm(acpi_desc, nfit_mem, device_handle); 1984 if (rc) 1985 continue; 1986 1987 /* 1988 * TODO: provide translation for non-NVDIMM_FAMILY_INTEL 1989 * devices (i.e. from nd_cmd to acpi_dsm) to standardize the 1990 * userspace interface. 1991 */ 1992 cmd_mask = 1UL << ND_CMD_CALL; 1993 if (nfit_mem->family == NVDIMM_FAMILY_INTEL) { 1994 /* 1995 * These commands have a 1:1 correspondence 1996 * between DSM payload and libnvdimm ioctl 1997 * payload format. 1998 */ 1999 cmd_mask |= nfit_mem->dsm_mask & NVDIMM_STANDARD_CMDMASK; 2000 } 2001 2002 /* Quirk to ignore LOCAL for labels on HYPERV DIMMs */ > 2003 if (nfit_mem->family == NVDIMM_FAMILY_HYPERV) 2004 set_bit(NDD_NOBLK, ); 2005 2006 if (test_bit(NFIT_MEM_LSR, _mem->flags)) { 2007 set_bit(ND_CMD_GET_CONFIG_SIZE, _mask); 2008 set_bit(ND_CMD_GET_CONFIG_DATA, _mask); 2009 } 2010 if (test_bit(NFIT_MEM_LSW, _mem->flags)) 2011 set_bit(ND_CMD_SET_CONFIG_DATA, _mask); 2012 2013 flush = nfit_mem->nfit_flush ? nfit_mem->nfit_flush->flush 2014 : NULL; 2015 nvdimm = __nvdimm_create(acpi_de
Re: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
Hi Dan, I love your patch! Yet something to improve: [auto build test ERROR on linux-nvdimm/libnvdimm-for-next] [also build test ERROR on v5.0-rc4 next-20190201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dan-Williams/libnvdimm-dimm-Add-a-no-BLK-quirk-based-on-NVDIMM-family/20190203-213444 base: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git libnvdimm-for-next config: x86_64-randconfig-x018-201905 (attached as .config) compiler: gcc-8 (Debian 8.2.0-14) 8.2.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/acpi//nfit/core.c: In function 'acpi_nfit_register_dimms': >> drivers/acpi//nfit/core.c:2003:27: error: 'NVDIMM_FAMILY_HYPERV' undeclared >> (first use in this function); did you mean 'NVDIMM_FAMILY_HPE2'? if (nfit_mem->family == NVDIMM_FAMILY_HYPERV) ^~~~ NVDIMM_FAMILY_HPE2 drivers/acpi//nfit/core.c:2003:27: note: each undeclared identifier is reported only once for each function it appears in vim +2003 drivers/acpi//nfit/core.c 1944 1945 static int acpi_nfit_register_dimms(struct acpi_nfit_desc *acpi_desc) 1946 { 1947 struct nfit_mem *nfit_mem; 1948 int dimm_count = 0, rc; 1949 struct nvdimm *nvdimm; 1950 1951 list_for_each_entry(nfit_mem, _desc->dimms, list) { 1952 struct acpi_nfit_flush_address *flush; 1953 unsigned long flags = 0, cmd_mask; 1954 struct nfit_memdev *nfit_memdev; 1955 u32 device_handle; 1956 u16 mem_flags; 1957 1958 device_handle = __to_nfit_memdev(nfit_mem)->device_handle; 1959 nvdimm = acpi_nfit_dimm_by_handle(acpi_desc, device_handle); 1960 if (nvdimm) { 1961 dimm_count++; 1962 continue; 1963 } 1964 1965 if (nfit_mem->bdw && nfit_mem->memdev_pmem) 1966 set_bit(NDD_ALIASING, ); 1967 1968 /* collate flags across all memdevs for this dimm */ 1969 list_for_each_entry(nfit_memdev, _desc->memdevs, list) { 1970 struct acpi_nfit_memory_map *dimm_memdev; 1971 1972 dimm_memdev = __to_nfit_memdev(nfit_mem); 1973 if (dimm_memdev->device_handle 1974 != nfit_memdev->memdev->device_handle) 1975 continue; 1976 dimm_memdev->flags |= nfit_memdev->memdev->flags; 1977 } 1978 1979 mem_flags = __to_nfit_memdev(nfit_mem)->flags; 1980 if (mem_flags & ACPI_NFIT_MEM_NOT_ARMED) 1981 set_bit(NDD_UNARMED, ); 1982 1983 rc = acpi_nfit_add_dimm(acpi_desc, nfit_mem, device_handle); 1984 if (rc) 1985 continue; 1986 1987 /* 1988 * TODO: provide translation for non-NVDIMM_FAMILY_INTEL 1989 * devices (i.e. from nd_cmd to acpi_dsm) to standardize the 1990 * userspace interface. 1991 */ 1992 cmd_mask = 1UL << ND_CMD_CALL; 1993 if (nfit_mem->family == NVDIMM_FAMILY_INTEL) { 1994 /* 1995 * These commands have a 1:1 correspondence 1996 * between DSM payload and libnvdimm ioctl 1997 * payload format. 1998 */ 1999 cmd_mask |= nfit_mem->dsm_mask & NVDIMM_STANDARD_CMDMASK; 2000 } 2001 2002 /* Quirk to ignore LOCAL for labels on HYPERV DIMMs */ > 2003 if (nfit_mem->family == NVDIMM_FAMILY_HYPERV) 2004 set_bit(NDD_NOBLK, ); 2005 2006 if (test_bit(NFIT_MEM_LSR, _mem->flags)) { 2007 set_bit(ND_CMD_GET_CONFIG_SIZE, _mask); 2008 set_bit(ND_CMD_GET_CONFIG_DATA, _mask); 2009 } 2010 if (test_bit(NFIT_MEM_LSW, _mem->flags)) 2011 set_bit(ND_CMD_SET_CONFIG_DATA, _mask); 2012 2013 flush = nfit_mem->nfit_flush ? nfit_mem->nfit_flush->flush 2014 : NULL; 2015 nvdimm = __nvdimm_create(acpi_de