From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::444; helo=mail-wr1-x444.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A4223208F7AA8 for ; Tue, 8 Jan 2019 07:46:04 -0800 (PST) Received: by mail-wr1-x444.google.com with SMTP id p4so4524081wrt.7 for ; Tue, 08 Jan 2019 07:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=g7qVkTaOagXvua4K31swQ6LW9c0YHruUNFUxSIBo23Q=; b=cHWynVuOa0wHDDKhJj4DMBFN47/D0zML/vZ2nxQeBgc5HOCQAxay2nXM0DmNnVu1ow uRcGfKer7R37DYBEkPve0kpPpJoIiSW0MJI/mpOslcVX3UdtRlZMXsVt71XJrLliY+2k AamTKJBUH+LOF9OyylJhm+R7faSmdUCLilETo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=g7qVkTaOagXvua4K31swQ6LW9c0YHruUNFUxSIBo23Q=; b=l0L9K0PwFvWlEBojcWQKdBhMy4qgH1M2DaiACbWNE7qCIbA6k30Xg9ndSEWribXwJ4 DmmYKLzwJu5ZQpZTFEQMwB4I8kCmP1LRj6f8t8qs5hstpwJdLHUiiAtxTVQkhFG1sZjh uhZhsWab7K3FFjiqjCWf1x5vXzGBTlNNfVgxjRYw1tz7nu7xvPlMs/u6XioFUssIPaF4 F+M65CClJmK08RFrh+Awx1X8jQ91MasgGbIpJl5RN9IekMGDXlLJClt6K6CdFg6xsZzG 9aoASbcyoBCSXcVQFz+oLO1I6Zk5RydMR5eYNUn/cmUYmOTN1ka0jQd/i12qTtYqujXS Cj8g== X-Gm-Message-State: AJcUukfFTY1Y5Qz/77794wWa8I+y4gie66DF5eAJxfdhGIVwlzA8Vkgs 4+UO+6y/MawxoxzY5d1xxmKa0g== X-Google-Smtp-Source: ALg8bN4Aed5Z5DIrrDSqWesnBa7a+FetqZEmoFYP4M5MxzcIVMpR32aG2/Swy09mPGQeRpABb8quDw== X-Received: by 2002:a5d:64c7:: with SMTP id y7mr1800426wrv.207.1546962362667; Tue, 08 Jan 2019 07:46:02 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id p10sm444384wrt.25.2019.01.08.07.46.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 08 Jan 2019 07:46:01 -0800 (PST) Date: Tue, 8 Jan 2019 15:45:59 +0000 From: Leif Lindholm To: "Gao, Liming" Cc: Laszlo Ersek , AKASHI Takahiro , Alexander Graf , Heinrich Schuchardt , "trini@konsulko.com" , "robdclark@gmail.com" , "u-boot@lists.denx.de" , "edk2-devel@lists.01.org" , "Wang, Jian J" , "Wu, Hao A" , "Ni, Ray" , "Zeng, Star" , Andrew Fish , "Kinney, Michael D" , Ard Biesheuvel , "Rothman, Michael A" Message-ID: <20190108154559.kty37kgoi6genlnv@bivouac.eciton.net> References: <20181217011626.GC14562@linaro.org> <84b6f3fd-ed68-a541-7727-69e5392984e6@suse.de> <20181225083024.GC14405@linaro.org> <20190107140932.uefkly3a3jzlyjjf@bivouac.eciton.net> <7d6fbbff-ca48-588a-6082-bf8b95a7e829@redhat.com> <20190107192220.ugkcxfd3betvuypi@bivouac.eciton.net> <1d1c1e2f-193c-5e1f-f51a-b922b67eb428@redhat.com> <20190108095102.myetfzaancuzq7cx@bivouac.eciton.net> <65b16f57-8d34-87ee-2fcc-8312d333f308@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E3ADCB9@SHSMSX152.ccr.corp.intel.com> MIME-Version: 1.0 In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E3ADCB9@SHSMSX152.ccr.corp.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 15:46:05 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Thanks Liming, this exactly the reply I was hoping for. On Tue, Jan 08, 2019 at 03:12:11PM +0000, Gao, Liming wrote: > EFI_GUID structure definition follows RFC UUID > https://www.ietf.org/rfc/rfc4122.txt. This RFC has no 64 bit > boundary requirement. I don't know the background why UEFI spec > requires to align on 64-bit boundary. This may be true for early IPF > arch. UEFI forum can clarify its purpose. If no specific reason, I > suggest to follow the industry standard GUID format, and update UEFI > spec. Since there would be no 64-bit alignment requirements for IPF either for correctness reasons, I expect it was added for performance reasons. > On pack in structure EFI_HII_KEYBOARD_LAYOUT, UEFI2.7 32.3 Code > Definitions has one sentence that this chapter describes the binary > encoding of the different package types. 32.3.3 Font Package has the > additional statement that structures described here are byte > packed. Base on those description, we can infer HII package data is > the byte packed. I agree to obviously specify that structures > described here are byte packed in 32.3 section. That sounds good to me. > Last, EFI_HII_KEYBOARD_PACKAGE_HDR structure definition doesn't > follow UEFI spec. I remember we ever meet with the compiler issue > for below style. GCC49 may complaint it. I need to double confirm. > typedef struct { > EFI_HII_PACKAGE_HEADER Header; > UINT16 LayoutCount; > EFI_HII_KEYBOARD_LAYOUT Layout[]; > } EFI_HII_KEYBOARD_PACKAGE_HDR; I did remark on this to Ard, and he pointed out the old compiler issue. If I delete those comment markers, I cannot reproduce a problem with either GCC48 or GCC49 (on those actual compiler versions) on ARM. Right, I will put together an email to USWG with you on cc. Regards, Leif > > Thanks > Liming > > -----Original Message----- > > From: Laszlo Ersek [mailto:lersek@redhat.com] > > Sent: Tuesday, January 8, 2019 7:56 PM > > To: Leif Lindholm > > Cc: AKASHI Takahiro ; Alexander Graf ; Heinrich Schuchardt ; > > trini@konsulko.com; robdclark@gmail.com; u-boot@lists.denx.de; edk2-devel@lists.01.org; Wang, Jian J ; Wu, > > Hao A ; Ni, Ray ; Zeng, Star ; Andrew Fish ; Kinney, > > Michael D ; Ard Biesheuvel ; Gao, Liming > > Subject: Re: [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols > > > > On 01/08/19 10:51, Leif Lindholm wrote: > > > MdePkg/MdeModulePkg maintainers - any comments? > > > > > > On Tue, Jan 08, 2019 at 01:28:00AM +0100, Laszlo Ersek wrote: > > >> On 01/07/19 20:22, Leif Lindholm wrote: > > >>> On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote: > > >> > > >>>> The UEFI spec (v2.7) explicitly requires EFI_GUID to be 64-bit aligned, > > >>>> unless specified otherwise. See in "Table 5. Common UEFI Data Types": > > >>>> > > >>>> EFI_GUID -- 128-bit buffer containing a unique identifier value. > > >>>> Unless otherwise specified, aligned on a 64-bit > > >>>> boundary. > > >>> > > >>> Indeed. > > >>> > > >>>> Whether edk2 satisfies that, and if so, how (by chance / by general > > >>>> build flags), I don't know. The code says, > > >>>> > > >>>> /// > > >>>> /// 128 bit buffer containing a unique identifier value. > > >>>> /// Unless otherwise specified, aligned on a 64 bit boundary. > > >>>> /// > > >>>> typedef struct { > > >>>> UINT32 Data1; > > >>>> UINT16 Data2; > > >>>> UINT16 Data3; > > >>>> UINT8 Data4[8]; > > >>>> } GUID; > > >>>> > > >>>> I think there may have been an expectation in "MdePkg/Include/Base.h" > > >>>> that the supported compilers would automatically ensure the specified > > >>>> alignment, given the structure definition. > > >>> > > >>> But that would be expecting things not only not guaranteed by C, but > > >>> something there is no semantic information suggesting would be useful > > >>> for the compiler to do above. [...] > > >> > > >> Agreed. I'm not saying the edk2 code is right, just guessing why the > > >> code might look like it does. This would not be the first silent > > >> assumption, I think. > > >> > > >> Anyhow, I think it would be better to change the code than the spec. > > > > > > Of course it would be better to change the code than the spec. > > > > > > But as Ard points out off-thread, doing (as a hack, with gcc) > > > > > > diff --git a/MdePkg/Include/Uefi/UefiBaseType.h > > > b/MdePkg/Include/Uefi/UefiBaseType.h > > > index 8c9d571eb1..75409f3460 100644 > > > --- a/MdePkg/Include/Uefi/UefiBaseType.h > > > +++ b/MdePkg/Include/Uefi/UefiBaseType.h > > > @@ -26,7 +26,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, > > > EITHER EXPRESS OR IMPLIED. > > > /// > > > /// 128-bit buffer containing a unique identifier value. > > > /// > > > -typedef GUID EFI_GUID; > > > +typedef GUID EFI_GUID __attribute__((aligned (8))); > > > /// > > > /// Function return status for EFI API. > > > /// > > > > > > breaks Linux boot on ARM (32-bit), since it inserts 32-bits of padding > > > between ConfigurationTable entries in the system table. > > > > ( > > > > More precisely, it adds padding to EFI_CONFIGURATION_TABLE after > > "VendorGuid" or after "VendorTable". Padding may not be added at the > > beginning of structures, and may not be added anywhere to arrays. > > > > The practical effect is the same, so this is just a side comment about C. > > > > ) > > > > Thanks > > Laszlo