Re: [edk2-devel] Question about UEFI, AddressSanitizer and MMU mappings

Hello, I have some experience porting LLVM Sanitizers and am very interested in this project coming live to UEFI as well. I had success with both entirely static shadow memory allocation and dynamic on-demand allocation. For ASan in the UEFI  my personal idea would be trying to avoid page-fault

Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix CPU stack guard support by aligning GDT buffer

Just to make it clear, this is an immediate solution that is good enough to fix the bug. However, a more proper solution would be to introduce the _Alignas ( https://en.cppreference.com/w/c/language/_Alignas ) concept to EDK II. I would suggest the following macro in Base.h: /** Enforce custom

Re: [edk2-devel] [Patch v9 2/2] MdePkg/Test/BaseLib: Add SAFE_STRING_CONSTRAINT_CHECK unit test

Time to get this land, thx Mike!Reviewed-By: Vitaly Cheptsov On Wed, May 20, 2020 at 23:10, Michael D Kinney wrote: Use the safe string function StrCpyS() in BaseLib to test theSAFE_STRING_CONSTRAINT_CHECK() macro.Cc: Andrew Fish Cc: Ard

Re: [edk2-devel] [Patch v9 2/2] MdePkg/Test/BaseLib: Add SAFE_STRING_CONSTRAINT_CHECK unit test

Time to get this land, thx Mike!Reviewed-By: Vitaly Cheptsov On Wed, May 20, 2020 at 23:10, Michael D Kinney wrote: Use the safe string function StrCpyS() in BaseLib to test theSAFE_STRING_CONSTRAINT_CHECK() macro.Cc: Andrew Fish Cc: Ard Biesheuvel Cc: Bret

Re: [edk2-devel] [Patch v8 2/2] MdePkg/Test/BaseLib: Add SAFE_STRING_CONSTRAINT_CHECK unit test

Mike, This looks generally good to me, but there are few issues. 1. There is a mistake in the description here: + // Negative test case with DestMax smaller than Source size + // + Status = StrCpyS (Destination, sizeof (Destination) / sizeof (CHAR16), Destination); This should read

Re: [edk2-devel] [Patch v8 1/2] MdePkg: Fix SafeString performing assertions on runtime checks

Mike, Looks perfect to me. For everyone: the only change from V7 is an addition of DEBUG_VERBOSE message, which can indeed be useful. Best wishes, Vitaly > 20 мая 2020 г., в 06:01, Michael D Kinney > написал(а): > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054 > > Runtime

Re: [edk2-devel] [PATCH 1/1] ShellPkg: Add support for input with separately reported modifiers

lt;mailto:zhichao@intel.com>> > > Thanks, > Zhichao > > <>From: vit9696 mailto:vit9...@protonmail.com>> > Sent: Wednesday, February 19, 2020 8:15 PM > To: Gao, Zhichao mailto:zhichao@intel.com>>; > devel@edk2.groups.io <mailto:devel@edk2.groups.io> &g

Re: [edk2-devel] [PATCH 1/1] ShellPkg: Add support for input with separately reported modifiers

update to remove the ambiguous and > reject other behavior -> removal the change in first step. > > Hi Vitaly, > > I used to think it is an additional support for different implementation > because of the spec. But if we approve this patch, all the app in edk2 using > t

Re: [edk2-devel] [PATCH 1/1] ShellPkg: Add support for input with separately reported modifiers

t below: > > > -Original Message- > > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> > > mailto:devel@edk2.groups.io>> On Behalf Of Vitaly > > Cheptsov via Groups.Io > > Sent: Monday, February 10, 2020 6:18 PM > > To: devel@edk2.groups.

Re: [edk2-devel] [PATCH 1/2] BaseTools: Change CLANGPDB target to reduce image size

Hello, While I can imagine this landing as an absolutely last effort resort, at the moment the problem is unclear and unjustified. Do not rush with this patch please and proceed with the discussion in BZ. Best wishes, Vitaly > 24 марта 2020 г., в 09:20, Zhiguang Liu написал(а): > > > REF:

Re: [edk2-devel] Patch List for 202002 stable tag

Liming, no problem from our side. The patch is now reviewed and I believe I provided all the necessarily material regarding its status. In case Ray would rather postpone it, I give no objection to this without prior notice. There is no problem from our side if EDK II team wants to prioritise

Re: [edk2-devel] [PATCH 1/1] ShellPkg: Add support for input with separately reported modifiers

> -Original Message- >> From: devel@edk2.groups.io On Behalf Of Vitaly >> Cheptsov via Groups.Io >> Sent: Monday, February 10, 2020 6:18 PM >> To: devel@edk2.groups.io >> Subject: [edk2-devel] [PATCH 1/1] ShellPkg: Add support for input with &

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

It seems that edk2.groups.io has hit the limits for message size due to quotation levels (?), so I send another copy of my previous message to have it visible from the web-interface. Andrew, It is ok, as we are all here for mutual benefit, no worries. But you are right

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

here necessary. >> >> I believe this way lines best with EDK II design. If there are no >> objections, I can submit the patch in the beginning of next week. >> >> Best wishes, >> Vitaly >> >>> 14 февр. 2020 г., в 20:00, Kinney, Michael D >>> написал(а): >

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

tOnSafeStringConstraints to be more generic, so if we find other lib >> APIs, the name will make sense? >> >> Maybe something like: PcdEnableLibraryAssertChecks? Default is TRUE. Can >> set to FALSE in DSC file to disable ASSERT() checks. >> >> Thanks, >>

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

dentify misuse > >> with trusted data and the API provides predicable > >> return behavior when ASSERT() is disabled, then I would > >> like to have a pattern we can potentially apply to all > >> these APIs across all packages. > >> > >> Thanks, > >&

Re: [edk2-devel] [PATCH 1/1] ShellPkg: Add support for input with separately reported modifiers

Replying as per Liming's request for this to be merged into edk2-stable202002. On Mon, Feb 10, 2020 at 13:18, Vitaly Cheptsov wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2510 > > Some firmwares: > - Report Shift modifier even when they report upper-case unicode letter. > -

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

; If we find other APIs where ASSERT() behavior is only >>> valuable during dev/debug to quickly identify misuse >>> with trusted data and the API provides predicable >>> return behavior when ASSERT() is disabled, then I would >>> like to have a pattern we can potentially a

Re: [edk2-devel] [PATCH 1/1] BaseTools: Switch to GNU mode for CLANGPDB

; > Thanks > > Liming > > From: devel@edk2.groups.io On Behalf Of Vitaly > Cheptsov via Groups.Io > Sent: Wednesday, February 12, 2020 4:08 PM > To: Liu, Zhiguang > Cc: devel@edk2.groups.io; Gao, Liming ; Shi, Steven > > Subject: Re: [edk2-devel] [PATCH 1/1]

Re: [edk2-devel] [PATCH 1/1] BaseTools: Switch to GNU mode for CLANGPDB

he > second patch 21821933aea284cd3dfea6994bd4b83bd9739fc9 has direct influence to > CLANG38. > > Thanks > Zhiguang > > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> > mailto:devel@edk2.groups.io>> On Behalf Of Vitaly > Cheptsov via Groups.Io >

Re: [edk2-devel] [PATCH 1/1] BaseTools: Switch to GNU mode for CLANGPDB

s change is good. Can you your test for it? I verify this patch for Ovmf > platform on Windows. It can make ovmf pass build with CLANGPDB. > > Thanks > Liming > > -Original Message- > > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> > > mailto:devel@e

[edk2-devel] [PATCH V2 0/1] BaseTools: Switch to GNU mode for CLANGPDB

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2397 I did not include __clang__ removal in this patch series, as it is also used in arm and aarch64 code, which makes me believe they could be using specialised toolchains. V2 performed a rebase onto recent master commits. Request this to be

Re: [edk2-devel] [PATCH 1/1] BaseTools: Switch to GNU mode for CLANGPDB

: > Vitaly: > This change is good. Can you your test for it? I verify this patch for Ovmf > platform on Windows. It can make ovmf pass build with CLANGPDB. > > Thanks > Liming >> -Original Message- >> From: devel@edk2.groups.io On Behalf Of Vitaly >> Ch

[edk2-devel] [PATCH 0/1] BaseTools: Switch to GNU mode for CLANGPDB

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2397 I did not include __clang__ removal in this patch series, as it is also used in arm and aarch64 code, which makes me believe they could be using specialised toolchains. Request this to be merged in edk2-stable202002. Vitaly Cheptsov (1):

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

pattern we can potentially apply to all >> these APIs across all packages. >> >> Thanks, >> >> Mike >> >>> -Original Message- >>> From: devel@edk2.groups.io On >>> Behalf Of Vitaly Cheptsov via Groups.Io >>> S

[edk2-devel] [PATCH 0/1] BaseTools: Switch to GNU mode for CLANGPDB

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2397 I did not include __clang__ removal in this patch series, as it is also used in arm and aarch64 code, which makes me believe they could be using specialised toolchains. Request this to be merged in edk2-stable202002. Vitaly Cheptsov (1):

[edk2-devel] [PATCH 1/1] BaseTools: Switch to GNU mode for CLANGPDB

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2397 Signed-off-by: Vitaly Cheptsov --- BaseTools/Conf/tools_def.template | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index

[edk2-devel] [PATCH 0/1] ShellPkg: Add support for input with separately reported modifiers

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2510 Some firmwares: - Report Shift modifier even when they report upper-case unicode letter. - Report Ctrl modifier with "shifted" UniChar (i.e. X - 'A' + 1). This change provides support for these firmwares preserving the compatibility with

Re: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC compiler

n keep the same behavior in > Windows/Linux/MacOs host OS. > > #if defined (__GNUC__) || defined (__clang__) > è > #if defined (__GNUC__) > > Thanks > Liming > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> > mailto:devel@edk2.groups.io>> On Behalf Of V

Re: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC compiler

lang__), another way is to investigate whether we can remove -fms-compatibility option in CLANGPDB.ThanksLiming> -Original Message-> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Vitaly Cheptsov via Groups.Io> Sent: Saturday, February 1, 2020 5:17 AM> To: dev

Re: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC compiler

TENSIONS) && !defined(__clang__), another way is to > investigate whether we can remove -fms-compatibility option in CLANGPDB. > > Thanks > Liming >> -Original Message----- >> From: devel@edk2.groups.io On Behalf Of Vitaly >> Cheptsov via Groups.Io >> Sen

[edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC compiler

Patch details are explained in https://bugzilla.tianocore.org/show_bug.cgi?id=2397. We request this to be merged in edk2-stable202002. Vitaly Cheptsov (1): MdePkg: Use _MSC_VER to determine MSVC compiler MdePkg/Include/AArch64/ProcessorBind.h | 2 +- MdePkg/Include/Arm/ProcessorBind.h |

[edk2-devel] [PATCH 1/1] MdePkg: Use _MSC_VER to determine MSVC compiler

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2397 CLANGPDB toolchain, implemented by clang compiler, will also define currently used _MSC_EXTENSIONS macro, which does not behave correctly in many situations as explained in the report. Signed-off-by: Vitaly Cheptsov ---

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

) is disabled, then I would > like to have a pattern we can potentially apply to all > these APIs across all packages. > > Thanks, > > Mike > >> -Original Message----- >> From: devel@edk2.groups.io On >> Behalf Of Vitaly Cheptsov via Groups.Io >> Sent:

Re: [edk2-devel] [PATCH 1/1] ShellPkg: Do not connect handles without device paths

your local version? >> >> >> Thanks, >> >> Ray >> >> >> From: devel@edk2.groups.io On Behalf Of Vitaly >> Cheptsov via Groups.Io >> Sent: Tuesday, January 14, 2020 4:47 AM >> To: Laszlo Ersek ; devel@edk2.groups.io;

Re: [edk2-devel] [PATCH 1/1] ShellPkg: Do not connect handles without device paths

: > Vitaly, > > I still have concern to modify the EDKII code to workaround a firmware bug. > > Can you just change in your local version? > > Thanks, > > Ray > > From: devel@edk2.groups.io On Behalf Of Vitaly > Cheptsov via Groups.Io > Sent: Tuesday, Janu

Re: [edk2-devel] [PATCH 1/1] ShellPkg: Do not connect handles without device paths

Thanks all for your input, These explanations seem sufficient to us that it is not a good idea to change the behaviour for everyone. Even so, we still need this to be configurable in some way, as having to patch EDK II is impracticable. We believe there are three possible routes to approach

Re: [edk2-devel] [PATCH 1/1] ShellPkg: Do not connect handles without device paths

ior of 'load' may be incorrect. > Is the option '-nc' working for your request? > > Thanks, > Zhichao > >> -Original Message- >> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of >> Vitaly Cheptsov via Groups.Io >> Sent: Monday, January

[edk2-devel] [PATCH 1/1] ShellPkg: Do not connect handles without device paths

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2460 Doing this reduces the amount of needless work during device connection and resolves issues with firmwares that freeze when connecting handles without device paths. Signed-off-by: Vitaly Cheptsov ---

[edk2-devel] [PATCH 0/1] ShellPkg: Do not connect handles without device paths

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2460 Doing this reduces the amount of needless work during device connection and resolves issues with firmwares that freeze when connecting handles without device paths. We request this to be merged in edk2-stable202002. Vitaly Cheptsov (1):

[edk2-devel] [PATCH v2 1/1] MdePkg: Do not use CreateEventEx unless required

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2446 There are many firmwares in the wild not supporting CreateEventEx, including devices less than 5 years old. Signed-off-by: Vitaly Cheptsov --- MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf | 3 ---

[edk2-devel] [PATCH v2 0/1] MdePkg: Do not use CreateEventEx unless required

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D2446 Changes from V1: - Dropped GUIDs from inf files Requesting for merge in edk2-stable202002 Vitaly Cheptsov (1): MdePkg: Do not use CreateEventEx unless required

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

APIs that currently document their ASSERT() > behavior and we think that ASSERT() behavior is incorrect and > should be handled by an existing error return value, then we > should discuss each of those APIs individually. > > Mike > > >> -Original Message- >> From: de

[edk2-devel] [PATCH v1 1/1] MdePkg: Do not use CreateEventEx unless required

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2446 There are many firmwares in the wild not supporting CreateEventEx, including devices less than 5 years old. Signed-off-by: Vitaly Cheptsov --- MdePkg/Library/DxeRuntimeDebugLibSerialPort/DebugLib.c | 3 +--

[edk2-devel] [PATCH v1 0/1] MdePkg: Do not use CreateEventEx unless required

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2446 Vitaly Cheptsov (1): MdePkg: Do not use CreateEventEx unless required MdePkg/Library/DxeRuntimeDebugLibSerialPort/DebugLib.c | 3 +-- MdePkg/Library/DxeRuntimePciExpressLib/PciExpressLib.c | 5 ++---

[edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054 Requesting for merge in edk2-stable202002. Changes since V1: - Enable assertions by default to preserve the original behaviour - Fix bugzilla reference link - Update documentation in BaseLib.h Vitaly Cheptsov (1): MdePkg: Add PCD to

[edk2-devel] [PATCH v3 1/1] MdePkg: Add PCD to disable safe string constraint assertions

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054 Runtime data checks are not meant to cause debug assertions unless explicitly needed by some debug code (thus the PCD) as this breaks debug builds validating data with BaseLib. Signed-off-by: Vitaly Cheptsov --- MdePkg/MdePkg.dec

Re: [edk2-devel] [PATCH V3 2/2] MdePkg/dsc: Add UefiDevicePathLibMandatoryDevicePathProtocol for build

Reviewed-by: Vitaly Cheptsov On Wed, Dec 18, 2019 at 05:10, Zhichao Gao wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298 > > Add the new instance lib for build. > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Vitaly Cheptsov > Reviewed-by: Liming Gao > Tested-by: Zhichao

Re: [edk2-devel] [PATCH V3 1/2] MdePkg/UefiDevicePathLib: Separate the device path lib

Reviewed-by: Vitaly Cheptsov On Wed, Dec 18, 2019 at 05:10, Zhichao Gao wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298 > > UefiDevicePathLibOptionalDevicePathProtocol's implementation isn't > fit its description. It should be implement as blow: > Try to find the

Re: [edk2-devel] [PATCH V3 0/2] *MdePkg/UefiDevicePathLib: Separate the lib instances

This makes very good sense to me, thank you for taking your time to fix it. I am slightly unsure whether if checks with subsequent assertions are really needed in mandatory version, as asserting in the constructor will trigger missing protocol very early anyway, but I do not think it is

Re: [edk2-devel] [PATCH v2 092/105] .mailmap: Add an entry for Vitaly Cheptsov

ilmap > index 9ff770c545bc..f2bc63d7b9ed 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -176,3 +176,4 @@ Ting Ye > > Ting Ye > Tomas Pilar > Vanguput Narendra > +Vitaly Cheptsov Vitaly Cheptsov via Groups.Io > > -- > 2.21.0 -=-=-=-=-=-=-=-=-=-=-=- Groups.

Re: [edk2-devel] [PATCH v3 1/1] MdePkg: Add PCD to disable safe string constraint assertions

, if an error would be > returned, then the function will NOT ASSERT(). > === > > > Hi Michael D Kinney > Do you have some comment? > > Thank you > Yao Jiewen > > >> -Original Message- >> From: devel@edk2.groups.io On

[edk2-devel] [PATCH v3 0/1] MdePkg: Add PCD to disable safe string constraint assertions

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054 Requesting for merge in edk2-stable2019011. Changes since V1: - Enable assertions by default to preserve the original behaviour - Fix bugzilla reference link Vitaly Cheptsov (1): MdePkg: Add PCD to disable safe string constraint

[edk2-devel] [PATCH v3 1/1] MdePkg: Add PCD to disable safe string constraint assertions

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054 Runtime data checks are not meant to cause debug assertions unless explicitly needed by some debug code (thus the PCD) as this breaks debug builds validating data with BaseLib. Signed-off-by: Vitaly Cheptsov > --- MdePkg/MdePkg.dec

[edk2-devel] [PATCH v2 0/1] MdePkg: Add PCD to disable safe string constraint assertions

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D2054 Requesting for merge in edk2-stable2019011. Vitaly Cheptsov (1): MdePkg: Add PCD to disable safe string constraint assertions MdePkg/MdePkg.dec | 6 ++ MdePkg/Library/BaseLib/BaseLib.inf | 11 ++-

[edk2-devel] [PATCH v2 1/1] MdePkg: Add PCD to disable safe string constraint assertions

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054 Runtime data checks are not meant to cause debug assertions unless explicitly needed by some debug code (thus the PCD) as this breaks debug builds validating data with BaseLib. Signed-off-by: Vitaly Cheptsov > --- MdePkg/MdePkg.dec

Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe string constraint assertions

hing never happen. (We still use error handling followed >> by to >> handle the release build.) >> > >> > This API is NOT design to handle untrusted input. As such, we believe it is >> expected ASSERT behavior. >> > >> > >> > We have other de

Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe string constraint assertions

r guarantee that, instead > of callee check that. And ASSERT is a good way to catch the issue as early as > possible. > > > > Thank you > Yao Jiewen > >> -Original Message- >> From: devel@edk2.groups.io On Behalf Of Vitaly >> Cheptsov via Groups.Io >>

Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe string constraint assertions

asically, to keep the compatible behavior, PcdAssertOnSafeStringConstraints >> default value should be TRUE. >> The different platform can configure it. >> >> Thanks >> Liming >>> -Original Message- >>> From: devel@edk2.groups.io [mailto:devel@e

[edk2-devel] [PATCH v1 0/1] MdePkg: Add PCD to disable safe string constraint assertions

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054 Requesting for merge in edk2-stable2019011. Vitaly Cheptsov (1): MdePkg: Add PCD to disable safe string constraint assertions MdePkg/MdePkg.dec | 6 ++ MdePkg/Library/BaseLib/BaseLib.inf | 11 ++-

[edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe string constraint assertions

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054 Runtime data checks are not meant to cause debug assertions unless explicitly needed by some debug code (thus the PCD) as this breaks debug builds validating data with BaseLib. Signed-off-by: Vitaly Cheptsov > --- MdePkg/MdePkg.dec

Re: [edk2-devel] [PATCH v3 1/1] MdePkg: Add STATIC_ASSERT macro

https://edk2.groups.io/g/devel/message/45691> gives RB. > > If no other comments, I will push this change this week. > > Thanks > Liming > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> > [mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>] On Behal

Re: [edk2-devel] [PATCH v3 1/1] MdePkg: Add STATIC_ASSERT macro

Hello, Given that new EDK II stable has already landed, and it was suggested to merge this right afterwards, it seems to me about the time to merge this patch. Best wishes, Vitaly -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#47003):

Re: [edk2-devel] Determining TSC frequency programmatically

.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/EmuThunk.c#L250> > > > I would point that a library that did TSC frequency discovery would likely be > useful for the UefiCpuPkg CpuDxe driver. > > Thanks, > > Andrew Fish > >> On Aug 15, 2019, at 2:10 PM, Vi

[edk2-devel] [PATCH v1 3/3] MdePkg: Drop VERIFY_SIZE_OF in favour of STATIC_ASSERT

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048 New STATIC_ASSERT macro supersedes VERIFY_SIZE_OF as being more functional. Signed-off-by: Vitaly Cheptsov --- MdePkg/Include/Base.h | 13 - 1 file changed, 13 deletions(-) diff --git a/MdePkg/Include/Base.h

[edk2-devel] [PATCH v1 0/3] Replace VERIFY_SIZE_OF with STATIC_ASSERT

Things to note: - This patchset should go after STATIC_ASSERT implementation: https://edk2.groups.io/g/devel/topic/32917749 - It is suggested that unlike the previous patch, which in my opinion should appear in edk2-stable201908, this patchset should land in edk2-stable2019011. This will

[edk2-devel] [PATCH v1 1/3] MdeModulePkg/ResetUtilityLib: Use STATIC_ASSERT macro

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048 Use new STATIC_ASSERT macro instead of VERIFY_SIZE_OF. Signed-off-by: Vitaly Cheptsov --- MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[edk2-devel] [PATCH v1 2/3] MdePkg: Use STATIC_ASSERT macro

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048 Use new STATIC_ASSERT macro instead of VERIFY_SIZE_OF. Signed-off-by: Vitaly Cheptsov --- MdePkg/Include/Base.h | 79 ++-- 1 file changed, 40 insertions(+), 39 deletions(-) diff --git a/MdePkg/Include/Base.h

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

members. A couple years ago that was still there just because there still existed some compilers that did not support [] syntax. Best wishes, Vitaly > 17 авг. 2019 г., в 1:58, Andrew Fish написал(а): > > > >> On Aug 16, 2019, at 2:40 PM, Vitaly Cheptsov via Groups.Io

[edk2-devel] [PATCH v3 1/1] MdePkg: Add STATIC_ASSERT macro

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048 Provide a macro for compile time assertions. Equivalent to C11 static_assert macro from assert.h. Signed-off-by: Vitaly Cheptsov --- MdePkg/Include/Base.h | 14 ++ 1 file changed, 14 insertions(+) diff --git

[edk2-devel] [PATCH v3 0/1] MdePkg: Add STATIC_ASSERT macro

Implements https://bugzilla.tianocore.org/show_bug.cgi?id=3D2048. Things to note: - _Static_assert is a standard C11 keyword and thus is available on every modern compiler (including Apple Clang, Clang, and GCC). See: https://en.cppreference.com/w/c/keyword/_Static_assert - static_assert is a

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

Mike, I missed your message while writing mine, but I am afraid I disagree with the functional macro usage for this feature. I explicitly quoted C standard static_assert definition in one of my previous messages, and I want EDK II to be as close to standard C as possible. This will avoid a

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

Laszlo, I am very glad to you for expressing a different opinion as this lets me view the situation from different angles. I understand your concerns, and believe that most of them should actually be addressed in a way you explain. In fact, I plan to submit more patches myself for everyone's

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

Laszlo, I have already mentioned that the documentation is sufficient as _Static_assert is C standard, so I do not plan to make a V3 for this patch. The patch is merge ready. As for usage examples I have an opposing opinion to yours and believe it is based on very good reasons. Not using

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

me HW assumptions that helps keep > the FW init code small and efficient. This does imply that different > libraries may be required for FW init and UEFI Applications. > > Thanks, > > Mike > > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> > [mailto:d

[edk2-devel] Determining TSC frequency programmatically

Hello, I initially raised this question in a new TimerLib patch[1], but as the discussion was getting more distracted, I decided to create a separate thread in hopes new people could join. The issue is that our UEFI bootloader needs to obtain TSC frequency to pass it to our specialised

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

Hi Donald, Glad to hear it helped a little, and sorry for some outdated quotes. Your clarification regarding model range is very helpful. Xeon W being client and thus having client clock makes sense, though I must say it was quite not obvious. I was referring to the same SDM table, and it

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

Hello, Thank you for the patch! I reviewed the code and noticed select issues explained below. 1. The following construction: if (RegEbx == 0) { DEBUG ((DEBUG_ERROR, "The CPU is not capble for Core Crystal Clock Frequency !!\n")); ASSERT (RegEbx != 0); } Does not look good to me, and in my