Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755756AbbEURol (ORCPT ); Thu, 21 May 2015 13:44:41 -0400 Received: from g4t3427.houston.hp.com ([15.201.208.55]:55450 "EHLO g4t3427.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752173AbbEURoh (ORCPT ); Thu, 21 May 2015 13:44:37 -0400 Message-ID: <1432229114.28126.25.camel@misato.fc.hp.com> Subject: Re: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure and NFIT support From: Toshi Kani To: Dan Williams Cc: Jens Axboe , "linux-nvdimm@lists.01.org" , Neil Brown , Greg KH , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Robert Moore , Linux ACPI , Lv Zheng , Christoph Hellwig , Ingo Molnar Date: Thu, 21 May 2015 11:25:14 -0600 In-Reply-To: References: <20150520205536.32249.89779.stgit@dwillia2-desk3.amr.corp.intel.com> <20150520205621.32249.39424.stgit@dwillia2-desk3.amr.corp.intel.com> <1432216514.26714.4.camel@misato.fc.hp.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4134 Lines: 107 On Thu, 2015-05-21 at 08:56 -0700, Dan Williams wrote: > On Thu, May 21, 2015 at 6:55 AM, Toshi Kani wrote: > > On Wed, 2015-05-20 at 16:56 -0400, Dan Williams wrote: > > : > >> +/* NVDIMM - NFIT table */ > >> + > >> +#define UUID_VOLATILE_MEMORY "4f940573-dafd-e344-b16c-3f22d252e5d0" > >> +#define UUID_PERSISTENT_MEMORY "79d3f066-f3b4-7440-ac43-0d3318b78cdb" > >> +#define UUID_CONTROL_REGION "f601f792-b413-5d40-910b-299367e8234c" > >> +#define UUID_DATA_REGION "3005af91-865d-0e47-a6b0-0a2db9408249" > >> +#define UUID_VOLATILE_VIRTUAL_DISK "5a53ab77-fc45-4b62-5560-f7b281d1f96e" > >> +#define UUID_VOLATILE_VIRTUAL_CD "30bd5a3d-7541-ce87-6d64-d2ade523c4bb" > >> +#define UUID_PERSISTENT_VIRTUAL_DISK "c902ea5c-074d-69d3-269f-4496fbe096f9" > >> +#define UUID_PERSISTENT_VIRTUAL_CD "88810108-cd42-48bb-100f-5387d53ded3d" > > > > acpi_str_to_uuid() performs little-endian byte-swapping, so the UUID > > strings here need to be actual values. > > > > For instance, UUID_PERSISTENT_MEMORY should be: > > #define UUID_PERSISTENT_MEMORY "66f0d379-b4f3-4074-ac43-0d3318b78cdb" > > > > No, the spec defines the GUID for persistent memory as: > > { 0x66F0D379, 0xB4F3, 0x4074, 0xAC, 0x43, 0x0D, 0x33, 0x18, 0xB7, 0x8C, 0xDB } > > The byte encoding for that GUID is the following (all fields stored > big endian: https://en.wikipedia.org/wiki/Globally_unique_identifier#Binary_encoding) > > { 0x66, 0xF0, 0xD3, 0x79, 0xB4, 0xF3, 0x40,0x74, 0xAC, 0x43, 0x0D, > 0x33, 0x18, 0xB7, 0x8C, 0xDB } > > The reverse ACPI string translation of a UUID buffer according to > "ACPI 6 - 19.6.136 ToUUID (Convert String to UUID Macro)" > > { dd, cc, bb, aa, ff, ee, hh, gg, ii, jj, kk, ll, mm, nn, oo, pp } > > "aabbccdd-eeff-gghh-iijj-kkllmmnnoopp" > > "79d3f066-f3b4-7440-ac43-0d3318b78cdb" > > Indeed, v2 of this patchset got this wrong. Thanks to the sharp eyes > of Bob Moore on the ACPICA team, he caught this discrepancy. It seems > the ACPI spec uses the terms "GUID" and "UUID" interchangeably. I agree that this thing is confusing... The Wiki page you pointed states that: === Byte encoding : This endianness applies only to the way in which a GUID is stored, and not to the way in which it is represented in text. GUIDs and RFC 4122 UUIDs should be identical when displayed textually. Text encoding : For the first three fields, the most significant digit is on the left. === Wiki page of UUID below also states that: http://en.wikipedia.org/wiki/Universally_unique_identifier === Definition : The first 3 sequences are interpreted as complete hexadecimal numbers, while the final 2 as a plain sequence of bytes. The byte order is "most significant byte first (known as network byte order) === So, the text encoding of GUID represents actual value; no endianness applies here. So, the following GUID definition: { 0x66F0D379, 0xB4F3, 0x4074, 0xAC, 0x43, 0x0D, 0x33, 0x18, 0xB7, 0x8C, 0xDB } Should be text encoded as: "66f0d379-b4f3-4074-ac43-0d3318b78cdb" Now, byte-encoding is confusing. While the Wiki page you pointed states that GUID has big endian per Microsoft definition, EFI spec defines differently. Please look at EFI 2.5 "Appendix A GUID and Time Formats". The EFI spec states that: === All EFI GUIDs (Globally Unique Identifiers) have the format described in RFC 4122 and comply with the referenced algorithms for generating GUIDs. It should be noted that TimeLow, TimeMid, TimeHighAndVersion fields in the EFI are encoded as little endian. === Table 212 defines how text representation of the GUID is stored in Buffer, which is little endian format. This table also states that the most significant byte is the first in text encoding, which is consistent with the Wiki pages. The ACPI spec, ToUUID, is consistent with EFI spec Table 212 as well. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/