RE: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure and NFIT support

[Moore, Robert]

It looks to me that you are correct and I screwed up when I made those strings. The odd thing is that we had discussed this whole issue internally for a few days -- then I went ahead and messed up the strings. I think my brain was going around in circles.

Anyway, here is the latest info, please have a look:


Below is the GUID for volatile memory region directly from the ACPI spec:


{ 0x7305944F, 0xFDDA, 0x44E3, 0xB1, 0x6C, 0x3F, 0x22, 0xD2, 0x52, 0xE5, 0xD0 }

Here is an example of ToUUID using a corrected version of the GUID string. Note that the ordering of the string is identical to the version in the ACPI spec:

      11:      Name (UUID, ToUUID ("7305944F-FDDA-44E3-B16C-3F22D252E5D0"))


Here is the AML output of the ToUUID macro. Note that the first three fields are reversed, the rest of the string is left as-is (as per the ToUUID definition):

00000024:  08 55 55 49 44 .........    ".UUID"
00000029:  11 13 0A 10 4F 94 05 73     "....O..s"
00000031:  DA FD E3 44 B1 6C 3F 22     "...D.l?""
00000039:  D2 52 E5 D0 ............    ".R.."

This is the important part:

           4F 94 05 73     "....O..s"
00000031:  DA FD E3 44 B1 6C 3F 22     "...D.l?""
00000039:  D2 52 E5 D0


I believe that this is correct.

Thanks for your help,
Bob




> -----Original Message-----
> From: Dan Williams [mailto:dan.j.williams@xxxxxxxxx]
> Sent: Thursday, May 21, 2015 2:35 PM
> To: Linda Knippers
> Cc: Toshi Kani; Jens Axboe; linux-nvdimm@xxxxxxxxxxxx; Neil Brown; Greg
> KH; Wysocki, Rafael J; Moore, Robert; linux-kernel@xxxxxxxxxxxxxxx; Linux
> ACPI; Ingo Molnar; Zheng, Lv; Christoph Hellwig
> Subject: Re: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure
> and NFIT support
> 
> On Thu, May 21, 2015 at 1:59 PM, Linda Knippers <linda.knippers@xxxxxx>
> wrote:
> > On 05/21/2015 03:59 PM, Toshi Kani wrote:
> >> On Thu, 2015-05-21 at 13:44 -0600, Toshi Kani wrote:
> >>> On Thu, 2015-05-21 at 12:06 -0700, Dan Williams wrote:
> >>>> On Thu, May 21, 2015 at 11:01 AM, Toshi Kani <toshi.kani@xxxxxx>
> wrote:
> >>>>> On Thu, 2015-05-21 at 17:49 +0000, Moore, Robert wrote:
> >>>>>> What ACPICA has done here is to define these values consistently
> with the ToUUID ASL macro:
> >>>>>>
> >>>>>>
> >>>>>> Byte encoding of UUID/GUID strings into ACPI Buffer objects (use
> ToUUID from ASL):
> >>>>>>
> >>>>>>    Input UUID/GUID String format : aabbccdd-eeff-gghh-iijj-
> kkllmmnnoopp
> >>>>>>      Expected output ACPI buffer : dd,cc,bb,aa, ff,ee, hh,gg,
> >>>>>> ii,jj, kk,ll,mm,nn,oo,pp
> >>>>>>
> >>>>>
> >>>>> I do not see any issue in this conversion, which is consistent
> >>>>> with ToUUID defined in ACPI spec.
> >>>>>
> >>>>> My point is that the string format of GUID is endian-neutral.
> >>>>> Wiki pages and EFI spec agree on it.  EFI 2.5 spec, Table 225
> >>>>> (sorry not Table 212, which is v2.4), is also clear about how
> >>>>> String and Buffer are related with actual values of GUID.
> >>>>
> >>>> I think the critical point from the UEFI spec is the "It should
> >>>> also be noted that TimeLow, TimeMid, TimeHighAndVersion fields in
> >>>> the EFI are encoded as little endian".  That would imply the byte
> >>>> encoding of...
> >>>>
> >>>> { 0x92F701F6, 0x13B4, 0x405D, 0x91, 0x0B, 0x29, 0x93, 0x67, 0xE8,
> >>>> 0x23, 0x4C }
> >>>>
> >>>> ...should be:
> >>>>
> >>>> { f6,01,f7,92,b4,13,5d,40,91,0b,29,93,67,e8,23,4c }
> >>>
> >>> The above NFIT GUID as data values means:
> >>>
> >>> EFI_GUID(0x92F701F6, 0x13B4, 0x405D, 0x91, 0x0B, 0x29, 0x93, 0x67,
> >>> 0xE8, 0x23, 0x4C)
> >>>
> >>>> Which implies the text conversion should be:
> >>>>
> >>>> "92f701f6-13b4-405d-910b-299367e8234c"
> >>>
> >>> Nope.
> >>
> >> Oops! Sorry, I misread your email... The above string is correct,
> >> although I do not think you need such conversion.
> >>
> >>> EFI 2.5 spec, Appendix A "GUID and Time Formats" defines that:
> >>> (NOTE, I simplified the table 225 to fit in this email) == This
> >>> specification also defines a standard text representation of the
> >>> GUID. This format is also sometimes called the âregistry formatâ. It
> >>> consists of 36 characters, as follows:
> >>>
> >>> aabbccdd-eeff-gghh-iijj-kkllmmnnoopp
> >>>  :
> >>>
> >>> Table 225. Text representation relationships
> >>> String       Offset In Buffer   EFI_GUID
> >>> aa   3                  Data1[24:31]
> >>> bb      2                  Data1[16:23]
> >>> cc      1                  Data1[8:15]
> >>> dd      0                  Data1[0:7]
> >>>  :
> >>> ===
> >>>
> >>> Therefore:
> >>>
> >>> aa = Data1[21:31] = 92
> >>> bb = Data1[16:23] = F7
> >>> cc = Data1[8:15]  = 01
> >>> dd = Data1[0:7]   = F6
> >>>
> >>>> ...not
> >>>>
> >>>>> +#define UUID_CONTROL_REGION             "f601f792-b413-5d40-910b-
> 299367e8234c"
> >>>
> >>> Hence, the above string is correct.
> >>
> >> Misread again... Right, the above string is NOT correct.
> >>
> >> I think we are on the same page that the GUID strings in this patch
> >> need to be changed.
> >>
> >> { 0x92F701F6, 0x13B4, 0x405D, 0x91, 0x0B, 0x29, 0x93, 0x67, 0xE8,
> >> 0x23, 0x4C }
> >>
> >> should be defined as:
> >>
> >> "92f701f6-13b4-405d-910b-299367e8234c"
> >
> > I've lost track of the right answer but should we be discussing it in
> > the context of this patch too?
> >
> > http://www.spinics.net/lists/linux-acpi/msg57825.html
> > [PATCH 18/19] ACPICA: ACPI 6.0: Add support for NFIT table.
> >
> > Dan's version of the file has lots of other UUIDs too, beyond NFIT.
> 
> Yeah, it's not clear whether those other GUIDs are actually GUIDs or these
> byte-swapped "EFI GUID"s.  At least for NFIT it seems that the intent was
> EFI GUID ordering due to the note about needing to match the "Disk Type
> GUID" format from the EFI spec.
> 
> I circle back with the ACPICA folks.