|
From: | Xiao Guangrong |
Subject: | Re: [Qemu-devel] [PATCH] nvdimm acpi: fix region format interface code |
Date: | Thu, 8 Jun 2017 14:40:29 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |