Re: [Qemu-devel] [PATCH] nvdimm acpi: fix region format interface code

[Dan Williams]

On Wed, Jun 7, 2017 at 11:50 PM, Haozhong Zhang
<address@hidden> 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 <address@hidden>
>> > > > ---
>> > > >    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.