| Message ID | 20170607080639.22120-1-haozhong.zhang@intel.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Jun 07, 2017 at 04:06:39PM +0800, Haozhong Zhang wrote: > Per ACPI 6.2, section 5.2.25.6 and JEDEC Annex L Release 3, the > current region format interface code 0x201 indicates the block > addressed function interface 1, rather than a byte addressable > interface. Fix it by using 0x301 which indicates the byte addressable > no energy backed function interface 1. > > Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> > --- > hw/acpi/nvdimm.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
On 06/07/2017 04:06 PM, Haozhong Zhang wrote: > Per ACPI 6.2, section 5.2.25.6 and JEDEC Annex L Release 3, the > current region format interface code 0x201 indicates the block > addressed function interface 1, rather than a byte addressable > interface. Fix it by using 0x301 which indicates the byte addressable > no energy backed function interface 1. > > Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> > --- > hw/acpi/nvdimm.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c > index 8e7d6ec034..b5734f5897 100644 > --- a/hw/acpi/nvdimm.c > +++ b/hw/acpi/nvdimm.c > @@ -338,9 +338,10 @@ static void nvdimm_build_structure_dcr(GArray *structures, DeviceState *dev) > nfit_dcr->revision_id = cpu_to_le16(1 /* Current Revision supported > in ACPI 6.0 is 1. */); > nfit_dcr->serial_number = cpu_to_le32(sn); > - nfit_dcr->fic = cpu_to_le16(0x201 /* Format Interface Code. See Chapter > - 2: NVDIMM Device Specific Method > - (DSM) in DSM Spec Rev1.*/); > + nfit_dcr->fic = cpu_to_le16(0x301 /* Format Interface Code: > + Byte addressable, no energy backed. > + See ACPI 6.2, sect 5.2.25.6 and > + JEDEC Annex L Release 3. */); Shouldn't the 'no energy backend' indicator be set only for !dax disk?
On 06/08/17 11:07 +0800, Xiao Guangrong wrote: > > > On 06/07/2017 04:06 PM, Haozhong Zhang wrote: > > Per ACPI 6.2, section 5.2.25.6 and JEDEC Annex L Release 3, the > > current region format interface code 0x201 indicates the block > > addressed function interface 1, rather than a byte addressable > > interface. Fix it by using 0x301 which indicates the byte addressable > > no energy backed function interface 1. > > > > Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> > > --- > > hw/acpi/nvdimm.c | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c > > index 8e7d6ec034..b5734f5897 100644 > > --- a/hw/acpi/nvdimm.c > > +++ b/hw/acpi/nvdimm.c > > @@ -338,9 +338,10 @@ static void nvdimm_build_structure_dcr(GArray *structures, DeviceState *dev) > > nfit_dcr->revision_id = cpu_to_le16(1 /* Current Revision supported > > in ACPI 6.0 is 1. */); > > nfit_dcr->serial_number = cpu_to_le32(sn); > > - nfit_dcr->fic = cpu_to_le16(0x201 /* Format Interface Code. See Chapter > > - 2: NVDIMM Device Specific Method > > - (DSM) in DSM Spec Rev1.*/); > > + nfit_dcr->fic = cpu_to_le16(0x301 /* Format Interface Code: > > + Byte addressable, no energy backed. > > + See ACPI 6.2, sect 5.2.25.6 and > > + JEDEC Annex L Release 3. */); > > Shouldn't the 'no energy backend' indicator be set only for !dax disk? Above specs define RFIC for two classes of byte-addressable NVDIMM: 1. 0x10[0|1]: A function containing byte addressable persistent memory whose persistence is achieved through the use of DRAM, nonvolatile memory (e.g., Flash) and an energy source. Only the DRAM portion is addressable by the system. 2. 0x30[0|1]: A function containing byte addressable persistent memory. All of the persistent memory is addressable by the system. No external energy source is required. If the last bit is 0, then it's a proprietary interface. The external backed energy is a mechanism that implements the persistence for the first class, and it's not required for the second class. The key point in this patch is RFIC provided by QEMU should indicate a *byte addressable* NVDIMM. Whether it's backed by the external energy does not matter much here, so I think it's free to choose one of them. Haozhong
On 06/08/2017 01:06 PM, Haozhong Zhang wrote: > On 06/08/17 11:07 +0800, Xiao Guangrong wrote: >> >> >> On 06/07/2017 04:06 PM, Haozhong Zhang wrote: >>> Per ACPI 6.2, section 5.2.25.6 and JEDEC Annex L Release 3, the >>> current region format interface code 0x201 indicates the block >>> addressed function interface 1, rather than a byte addressable >>> interface. Fix it by using 0x301 which indicates the byte addressable >>> no energy backed function interface 1. >>> >>> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> >>> --- >>> hw/acpi/nvdimm.c | 7 ++++--- >>> 1 file changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c >>> index 8e7d6ec034..b5734f5897 100644 >>> --- a/hw/acpi/nvdimm.c >>> +++ b/hw/acpi/nvdimm.c >>> @@ -338,9 +338,10 @@ static void nvdimm_build_structure_dcr(GArray *structures, DeviceState *dev) >>> nfit_dcr->revision_id = cpu_to_le16(1 /* Current Revision supported >>> in ACPI 6.0 is 1. */); >>> nfit_dcr->serial_number = cpu_to_le32(sn); >>> - nfit_dcr->fic = cpu_to_le16(0x201 /* Format Interface Code. See Chapter >>> - 2: NVDIMM Device Specific Method >>> - (DSM) in DSM Spec Rev1.*/); >>> + nfit_dcr->fic = cpu_to_le16(0x301 /* Format Interface Code: >>> + Byte addressable, no energy backed. >>> + See ACPI 6.2, sect 5.2.25.6 and >>> + JEDEC Annex L Release 3. */); >> >> Shouldn't the 'no energy backend' indicator be set only for !dax disk? > > Above specs define RFIC for two classes of byte-addressable NVDIMM: > 1. 0x10[0|1]: A function containing byte addressable persistent memory > whose persistence is achieved through the use of DRAM, > nonvolatile memory (e.g., Flash) and an energy source. > Only the DRAM portion is addressable by the system. > 2. 0x30[0|1]: A function containing byte addressable persistent > memory. All of the persistent memory is addressable by > the system. No external energy source is required. > If the last bit is 0, then it's a proprietary interface. As both of them indicate persistent memory, it is okay to me. The FIC, 0x201, comes from the document of Intel DSM example, i have no idea why it uses 0x201. Maybe it is worth being fixed too.
On 06/08/17 14:40 +0800, Xiao Guangrong wrote: > > > On 06/08/2017 01:06 PM, Haozhong Zhang wrote: > > On 06/08/17 11:07 +0800, Xiao Guangrong wrote: > > > > > > > > > On 06/07/2017 04:06 PM, Haozhong Zhang wrote: > > > > Per ACPI 6.2, section 5.2.25.6 and JEDEC Annex L Release 3, the > > > > current region format interface code 0x201 indicates the block > > > > addressed function interface 1, rather than a byte addressable > > > > interface. Fix it by using 0x301 which indicates the byte addressable > > > > no energy backed function interface 1. > > > > > > > > Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> > > > > --- > > > > hw/acpi/nvdimm.c | 7 ++++--- > > > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c > > > > index 8e7d6ec034..b5734f5897 100644 > > > > --- a/hw/acpi/nvdimm.c > > > > +++ b/hw/acpi/nvdimm.c > > > > @@ -338,9 +338,10 @@ static void nvdimm_build_structure_dcr(GArray *structures, DeviceState *dev) > > > > nfit_dcr->revision_id = cpu_to_le16(1 /* Current Revision supported > > > > in ACPI 6.0 is 1. */); > > > > nfit_dcr->serial_number = cpu_to_le32(sn); > > > > - nfit_dcr->fic = cpu_to_le16(0x201 /* Format Interface Code. See Chapter > > > > - 2: NVDIMM Device Specific Method > > > > - (DSM) in DSM Spec Rev1.*/); > > > > + nfit_dcr->fic = cpu_to_le16(0x301 /* Format Interface Code: > > > > + Byte addressable, no energy backed. > > > > + See ACPI 6.2, sect 5.2.25.6 and > > > > + JEDEC Annex L Release 3. */); > > > > > > Shouldn't the 'no energy backend' indicator be set only for !dax disk? > > > > Above specs define RFIC for two classes of byte-addressable NVDIMM: > > 1. 0x10[0|1]: A function containing byte addressable persistent memory > > whose persistence is achieved through the use of DRAM, > > nonvolatile memory (e.g., Flash) and an energy source. > > Only the DRAM portion is addressable by the system. > > 2. 0x30[0|1]: A function containing byte addressable persistent > > memory. All of the persistent memory is addressable by > > the system. No external energy source is required. > > If the last bit is 0, then it's a proprietary interface. > > As both of them indicate persistent memory, it is okay to me. > > The FIC, 0x201, comes from the document of Intel DSM example, i have no idea why > it uses 0x201. Maybe it is worth being fixed too. > I guess the reason is it's an example, e.g. "... describes an *example* _DSM interface for NVDIMM Device with Region Format Interface Code (RFIC) of 0x0201" at the beginning of Chapter 2. Haozhong
On Wed, Jun 7, 2017 at 11:50 PM, Haozhong Zhang <haozhong.zhang@intel.com> wrote: > On 06/08/17 14:40 +0800, Xiao Guangrong wrote: >> >> >> On 06/08/2017 01:06 PM, Haozhong Zhang wrote: >> > On 06/08/17 11:07 +0800, Xiao Guangrong wrote: >> > > >> > > >> > > On 06/07/2017 04:06 PM, Haozhong Zhang wrote: >> > > > Per ACPI 6.2, section 5.2.25.6 and JEDEC Annex L Release 3, the >> > > > current region format interface code 0x201 indicates the block >> > > > addressed function interface 1, rather than a byte addressable >> > > > interface. Fix it by using 0x301 which indicates the byte addressable >> > > > no energy backed function interface 1. >> > > > >> > > > Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> >> > > > --- >> > > > hw/acpi/nvdimm.c | 7 ++++--- >> > > > 1 file changed, 4 insertions(+), 3 deletions(-) >> > > > >> > > > diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c >> > > > index 8e7d6ec034..b5734f5897 100644 >> > > > --- a/hw/acpi/nvdimm.c >> > > > +++ b/hw/acpi/nvdimm.c >> > > > @@ -338,9 +338,10 @@ static void nvdimm_build_structure_dcr(GArray *structures, DeviceState *dev) >> > > > nfit_dcr->revision_id = cpu_to_le16(1 /* Current Revision supported >> > > > in ACPI 6.0 is 1. */); >> > > > nfit_dcr->serial_number = cpu_to_le32(sn); >> > > > - nfit_dcr->fic = cpu_to_le16(0x201 /* Format Interface Code. See Chapter >> > > > - 2: NVDIMM Device Specific Method >> > > > - (DSM) in DSM Spec Rev1.*/); >> > > > + nfit_dcr->fic = cpu_to_le16(0x301 /* Format Interface Code: >> > > > + Byte addressable, no energy backed. >> > > > + See ACPI 6.2, sect 5.2.25.6 and >> > > > + JEDEC Annex L Release 3. */); >> > > >> > > Shouldn't the 'no energy backend' indicator be set only for !dax disk? >> > >> > Above specs define RFIC for two classes of byte-addressable NVDIMM: >> > 1. 0x10[0|1]: A function containing byte addressable persistent memory >> > whose persistence is achieved through the use of DRAM, >> > nonvolatile memory (e.g., Flash) and an energy source. >> > Only the DRAM portion is addressable by the system. >> > 2. 0x30[0|1]: A function containing byte addressable persistent >> > memory. All of the persistent memory is addressable by >> > the system. No external energy source is required. >> > If the last bit is 0, then it's a proprietary interface. >> >> As both of them indicate persistent memory, it is okay to me. >> >> The FIC, 0x201, comes from the document of Intel DSM example, i have no idea why >> it uses 0x201. Maybe it is worth being fixed too. >> > > I guess the reason is it's an example, e.g. "... describes an > *example* _DSM interface for NVDIMM Device with Region Format > Interface Code (RFIC) of 0x0201" at the beginning of Chapter 2. The 0x201 vs 0x301 distinction is blk-aperture mode vs pmem mode namespaces. Other operating systems need this indication in the NFIT DIMM Control Region, Linux doesn't care and just uses the presence of blk-aperture tables as the indicator to whether a control region represent blk-mode vs pmem.
diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c index 8e7d6ec034..b5734f5897 100644 --- a/hw/acpi/nvdimm.c +++ b/hw/acpi/nvdimm.c @@ -338,9 +338,10 @@ static void nvdimm_build_structure_dcr(GArray *structures, DeviceState *dev) nfit_dcr->revision_id = cpu_to_le16(1 /* Current Revision supported in ACPI 6.0 is 1. */); nfit_dcr->serial_number = cpu_to_le32(sn); - nfit_dcr->fic = cpu_to_le16(0x201 /* Format Interface Code. See Chapter - 2: NVDIMM Device Specific Method - (DSM) in DSM Spec Rev1.*/); + nfit_dcr->fic = cpu_to_le16(0x301 /* Format Interface Code: + Byte addressable, no energy backed. + See ACPI 6.2, sect 5.2.25.6 and + JEDEC Annex L Release 3. */); } static GArray *nvdimm_build_device_structure(void)
Per ACPI 6.2, section 5.2.25.6 and JEDEC Annex L Release 3, the current region format interface code 0x201 indicates the block addressed function interface 1, rather than a byte addressable interface. Fix it by using 0x301 which indicates the byte addressable no energy backed function interface 1. Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> --- hw/acpi/nvdimm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)