From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 90C1321E70D3F for ; Tue, 29 Aug 2017 13:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1504039642; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EAlcDhPnlaaDoYFJltKdbBJwDSNK1hF30okNYWlPsW0=; b=GMWlISIYnaAU8/bsnHcOM4R9+mV6+4SHihcBym2Cl44hWgM1bQjg5OOdU65pIq/j 7dGaRPS7t2sLriwyPpjDASxeZELAy12ZuhpUj1MCpa6sbvPgNkpGYAv4HDrSKa8M LFhgdN6yPeAOxHzFSJvRPonW8LwtZJ8STVLiGBVX6jvPaYrhw8QWbWrpGP96t4MJ 3Hx1K0tRvTtF8JjGoY+Hj193vgv/lqTvGSaX1Jpl6qgzWCqsE7osX7gDIaVfooqB P9Q8UbzvUErnvFKeZ+e0vTnFWvTuscfcLCeAORxO/9bz/IEzwAe74LmdhPzbRaxf iUj4Fz3btA9FAyrpsEQETA==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 22.FC.30368.AD2D5A95; Tue, 29 Aug 2017 13:47:22 -0700 (PDT) X-AuditID: 11973e13-36fff700000076a0-1b-59a5d2da3f9c Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay7.apple.com (Apple SCV relay) with SMTP id B3.0E.07283.9D2D5A95; Tue, 29 Aug 2017 13:47:22 -0700 (PDT) MIME-version: 1.0 Received: from da0601a-dhcp66.apple.com ([17.226.15.66]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OVG00HATSEXJY40@nwk-mmpp-sz12.apple.com>; Tue, 29 Aug 2017 13:47:21 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: <50793747-50B9-49F5-BFA4-EE34D6913976@apple.com> Date: Tue, 29 Aug 2017 13:47:21 -0700 In-reply-to: <0a441b5d-3183-03b0-c5a4-fda92d7b01c1@redhat.com> Cc: Ard Biesheuvel , Ruiyu Ni , "edk2-devel@lists.01.org" , Liming Gao To: Laszlo Ersek References: <20170825085723.396044-1-ruiyu.ni@intel.com> <20170825085723.396044-5-ruiyu.ni@intel.com> <0a441b5d-3183-03b0-c5a4-fda92d7b01c1@redhat.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUi2FCYqnvr0tJIg6+ruS3+f9jNaLHn0FFm i2XHdrBYrLi3gd3iZc9qdgdWj8V7XjJ53Lm2h82je/Y/Fo/3+66yBbBEcdmkpOZklqUW6dsl cGUsmrqIqWDHOqaKzy+2Mjcwfupi6mLk5JAQMJG4v+sPWxcjF4eQwBomiWV9r9lgEi8vNoPZ QgKHGCX+7HEEsXkFBCV+TL7HAmIzC4RJPNvVxQrRPJFJov3aN3aQhLCAuMS7M5uYQWw2AWWJ FfM/AMU5gJptJDYvqYMoyZDYtOMtK4jNIqAqcWTiS7CZnAJ2Erf/TGICmckssJJRYlXTX7A5 IgIqErMnPGCCWPaIUWLpjCaoS2Ulbs2+xAySkBD4zCZx5lUD4wRGoVlIrp2F5FoIW0vi+6NW oDgHkC0vcfC8LERYU+LZvU/sELa2xJN3F1gXMLKtYhTKTczM0c3MM9VLLCjISdVLzs/dxAiK oel2wjsYT6+yOsQowMGoxMMrULE0Uog1say4MvcQozQHi5I4b9AFoJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGRUvubP3pYhlXGfBw/t9PfyJrt+rPslx5UOXLay5XXenarsh9YRKbdLwb csTOBZbF6iwIXj7rd+dfrv7ycwohh+p8WA2lGZ0OdISsv3njze06D2UR6adqhz9/+cyotc40 7+ItaYujjX73cxRf+avk2+2ukPrRkn9DVVitc7Plj3UrhSrFlFcrsRRnJBpqMRcVJwIArzSp RYICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJIsWRmVeSWpSXmKPExsUi2FB8RvfWpaWRBi+Pslr8/7Cb0WLPoaPM FsuO7WCxWHFvA7vFy57V7A6sHov3vGTyuHNtD5tH9+x/LB7v911lC2CJ4rJJSc3JLEst0rdL 4MpYNHURU8GOdUwVn19sZW5g/NTF1MXIySEhYCLx8mIzG4gtJHCIUeLPHkcQm1dAUOLH5Hss IDazQJjEs11drF2MXEA1E5kk2q99YwdJCAuIS7w7s4kZxGYTUJZYMf8DUJwDqNlGYvOSOoiS DIlNO96ygtgsAqoSRya+BJvJKWAncfvPJCaQmcwCKxklVjX9BZsjIqAiMXvCAyaIZY8YJZbO aGKDuFRW4tbsS8wTGPlnITlwFpIDIWwtie+PWoHiHEC2vMTB87IQYU2JZ/c+sUPY2hJP3l1g XcDItopRoCg1J7HSXC+xoCAnVS85P3cTIzjkC1N3MDYutzrEKMDBqMTDK1CxNFKINbGsuDIX GEgczEoivDvOA4V4UxIrq1KL8uOLSnNSiw8xTmQEenMis5Rocj4wIvNK4g1NTAxMjI3NjI3N TcxpKawkziuWsiRSSCA9sSQ1OzW1ILUI5igmDk6pBsao4NQ4+aqf23wjGz1Xbbwqwfkt+y3j vK3XPrz3Xim/6NHX5uty17P0A35POPvrHuOU825f86+uZLVYIba5yS2rLYn55faNofcsQ89u 8Dbb0eTgMjfxY6TR+V+6mc1fdNiW23nf+FVt76zwkK07YIUAg8vtHYdY6/PCeV7OXM/bWmMs tXV7TJQSS3FGoqEWc1FxIgDTbB767AIAAA== X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: Re: [PATCH v2 4/5] MdePkg/PciSegmentLib: Add instances that consumes PciSegmentInfoLib X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 20:44:41 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > On Aug 29, 2017, at 1:39 PM, Laszlo Ersek wrote: > > On 08/29/17 20:51, Ard Biesheuvel wrote: >> Hi, >> >> Some comments below. >> >> On 25 August 2017 at 09:57, Ruiyu Ni wrote: >>> The patch adds two PciSegmentLib instances that consumes >>> PciSegmentInfoLib to provide multiple segments PCI configuration >>> access. >>> >>> BasePciSegmentLibSegmentInfo instance is a BASE library. >>> DxeRuntimePciSegmentLibSegmentInfo instance is to be linked with >>> runtime drivers to provide not only boot time but also runtime >>> PCI configuration access. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.0 >>> Signed-off-by: Ruiyu Ni >>> Cc: Liming Gao >>> --- >>> .../PciSegmentLibSegmentInfo/BasePciSegmentLib.c | 71 + >>> .../BasePciSegmentLibSegmentInfo.inf | 46 + >>> .../BasePciSegmentLibSegmentInfo.uni | 21 + >>> .../DxeRuntimePciSegmentLib.c | 321 +++++ >>> .../DxeRuntimePciSegmentLibSegmentInfo.inf | 55 + >>> .../DxeRuntimePciSegmentLibSegmentInfo.uni | 21 + >>> .../PciSegmentLibSegmentInfo/PciSegmentLibCommon.c | 1375 ++++++++++++++++++++ >>> .../PciSegmentLibSegmentInfo/PciSegmentLibCommon.h | 57 + >>> MdePkg/MdePkg.dsc | 2 + >>> 9 files changed, 1969 insertions(+) >>> create mode 100644 MdePkg/Library/PciSegmentLibSegmentInfo/BasePciSegmentLib.c >>> create mode 100644 MdePkg/Library/PciSegmentLibSegmentInfo/BasePciSegmentLibSegmentInfo.inf >>> create mode 100644 MdePkg/Library/PciSegmentLibSegmentInfo/BasePciSegmentLibSegmentInfo.uni >>> create mode 100644 MdePkg/Library/PciSegmentLibSegmentInfo/DxeRuntimePciSegmentLib.c >>> create mode 100644 MdePkg/Library/PciSegmentLibSegmentInfo/DxeRuntimePciSegmentLibSegmentInfo.inf >>> create mode 100644 MdePkg/Library/PciSegmentLibSegmentInfo/DxeRuntimePciSegmentLibSegmentInfo.uni >>> create mode 100644 MdePkg/Library/PciSegmentLibSegmentInfo/PciSegmentLibCommon.c >>> create mode 100644 MdePkg/Library/PciSegmentLibSegmentInfo/PciSegmentLibCommon.h >>> >> [...] >>> diff --git a/MdePkg/Library/PciSegmentLibSegmentInfo/PciSegmentLibCommon.c b/MdePkg/Library/PciSegmentLibSegmentInfo/PciSegmentLibCommon.c >>> new file mode 100644 >>> index 0000000000..7b7324d673 >>> --- /dev/null >>> +++ b/MdePkg/Library/PciSegmentLibSegmentInfo/PciSegmentLibCommon.c >>> @@ -0,0 +1,1375 @@ >>> +/** @file >>> + Provide common routines used by BasePciSegmentLibSegmentInfo and >>> + DxeRuntimePciSegmentLibSegmentInfo libraries. >>> + >>> + Copyright (c) 2017, Intel Corporation. All rights reserved.
>>> + This program and the accompanying materials are >>> + licensed and made available under the terms and conditions of >>> + the BSD License which accompanies this distribution. The full >>> + text of the license may be found at >>> + http://opensource.org/licenses/bsd-license.php. >>> + >>> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, >>> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. >>> + >>> +**/ >>> + >>> +#include "PciSegmentLibCommon.h" >>> + >>> +typedef struct { >>> + UINT64 Register : 12; >>> + UINT64 Function : 3; >>> + UINT64 Device : 5; >>> + UINT64 Bus : 8; >>> + UINT64 Reserved1 : 4; >>> + UINT64 Segment : 16; >>> + UINT64 Reserved2 : 16; >>> +} PCI_SEGMENT_LIB_ADDRESS_STRUCTURE; >>> + >> >> Is this guaranteed to work as expected by the C spec? > > From C99, "6.7.2.1 Structure and union specifiers", paragraph 10: > > "An implementation may allocate any addressable storage unit large > enough to hold a bit-field. If enough space remains, a bit-field that > immediately follows another bit-field in a structure shall be packed > into adjacent bits of the same unit. If insufficient space remains, > whether a bit-field that does not fit is put into the next unit or > overlaps adjacent units is implementation-defined. The order of > allocation of bit-fields within a unit (high-order to low-order or > low-order to high-order) is implementation-defined. The alignment of the > addressable storage unit is unspecified." > > Due to the above, I consider bit-fields totally nonportable, and avoid > introducing bit-fields in any code I write. > > However, "implementation-defined" means the compiler docs have to > describe how bit-fields are laid out. If you know your toolchain (...all > of your toolchains...), I guess you can make them work. FWIW, edk2 is > chock-full of bit-fields. > > ... For example, the clang build options contain "-mms-bitfields": > Laszlo, FYI -mms-bitfields was to force EFI ABI compatibility, not to enabled bit fields per say. I can't remember why we used ms-bitfields vs. ms-struct? Thanks, Andrew Fish > https://clang.llvm.org/docs/ClangCommandLineReference.html > > --> "Set the default structure layout to be compatible with the > Microsoft compiler standard". > > The GCC docs are here: > > https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html > > --> "Determined by ABI." > > These structures make me shudder, but if they work, I just close my eyes > and move on. :/ > > Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel