> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Gao, Zhichao
> Sent: Tuesday, September 17, 2019 3:00 PM
> To: Ni, Ray
> Cc: Gris87; devel@edk2.groups.io
> Subject: Re: [edk2-devel] [PATCH] MdeModulePkg: Add missing sourceX for
> Blt
>
> It
Reviewed-by: Michael D Kinney
> -Original Message-
> From: Gao, Liming
> Sent: Tuesday, September 24, 2019 5:38 PM
> To: Leif Lindholm ;
> devel@edk2.groups.io
> Cc: Kinney, Michael D
> Subject: RE: [edk2-devel] [Patch] MdePkg Base.h: Define
> STATIC_ASSERT macro as empty for EBC arch
> -Original Message-
> From: Albecki, Mateusz
> Sent: Monday, September 23, 2019 4:37 PM
> To: devel@edk2.groups.io
> Cc: Albecki, Mateusz; Wu, Hao A; Marcin Wojtas
> Subject: [PATCH 1/1] MdeModulePkg/SdMmcPciHcDxe: Fix bus timing
> switch sequence
>
> SD specification recommends
No topics, so we'll cancel this week.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#48007): https://edk2.groups.io/g/devel/message/48007
Mute This Topic: https://groups.io/mt/34283833/21656
Mute #cal-cancelled:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCEL
CALSCALE:GREGORIAN
BEGIN:VEVENT
STATUS:CANCELLED
UID:calendar.15...@groups.io
DTSTAMP:20190925T022431Z
ORGANIZER;CN=Stephano Cetola:mailto:stephano.cet...@linux.intel.com
Hi Hao,
Could you help to push this V3 patch series?
Thanks,
Dandan
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Dandan Bi
> Sent: Tuesday, September 24, 2019 9:17 PM
> To: devel@edk2.groups.io
> Cc: Leif Lindholm ; Ard Biesheuvel
> ;
Laszlo:
>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Wednesday, September 25, 2019 1:27 AM
>To: Gao, Liming ; devel@edk2.groups.io
>Cc: Andrew Fish ; Leif Lindholm ;
>Kinney, Michael D
>Subject: Re: [Patch] Maintainers.txt: Move ShellBin maintainers to EDK II
On Tue, Sep 24, 2019 at 11:05:19PM +0800, Liming Gao wrote:
> EBC compiler doesn't support C11 static_assert macro.
> So, define STATIC_ASSERT as empty to pass EBC arch build.
> STATIC_ASSERT macro is introduced @204ae9da230ecbf0910c21acac7aa5d5e8cbb8d0
>
> Cc: Michael D Kinney
> Signed-off-by:
Reviewed-by: Ankit Sinha
-Original Message-
From: devel@edk2.groups.io On Behalf Of Kubacki, Michael
A
Sent: Tuesday, September 24, 2019 11:13 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L
; Sinha, Ankit ; Jeremy
Soller
Subject: [edk2-devel]
Hi Peter,
thanks for the patch. Two comments:
On 09/20/19 20:45, Peter Jones wrote:
> Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some
> tests check if it's defined or not. Additionally, in UefiPayloadPkg as
> well as some other trees, we define it as FALSE in the .dsc
On 09/24/19 07:54, Chiu, Chasel wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2212
>
> Current S3BootScriptLib can only support build time opt-out
I think this problem statement is wrong.
In the OVMF platform anyway, PiDxeS3BootScriptLib is linked into the following
two modules:
On Tue, Sep 24, 2019 at 01:55:47PM -0700, Michael Kubacki wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2217
>
> Python build is enabled for some platform code leading to .pyc files
> created in __pycache__ directories. This change adds the __pycache__
> directory to a .gitignore
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2217
Python build is enabled for some platform code leading to .pyc files
created in __pycache__ directories. This change adds the __pycache__
directory to a .gitignore file to allow git to ignore Python cache files.
Cc: Ard Biesheuvel
Cc:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2126
Avoid errors of type:
~/edk2/SctPkg/TestCase/RIVL/Protocol/Http/Http/HttpENTSTest.c:74:1:
error: conflicting types for ‘HttpENTSTestMain’
74 | HttpENTSTestMain (
| ^~~~
In file included from :
On 9/24/19 10:50 AM, xianhui liu wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2061
check MediaPresent while MediaPresentSupported is TRUE
sync change from EFI to IHV SimpleNetworkBBTestFunction
Thanks for addressing this issue.
Cc: Heinrich Schuchardt
%s/Cc:/Reported-by:/
On 9/24/19 8:42 AM, Laszlo Ersek wrote:
> On 09/19/19 21:52, Lendacky, Thomas wrote:
>> From: Tom Lendacky
>>
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
>>
>> During BSP startup, the reset vector code will issue a CPUID instruction
>> while in 32-bit mode. When running as an
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
EC command details may vary across Kaby Lake boards. This change moves
this set of EC commands to the KabylakeRvp3 directory since these
commands are specifically used by that board at this time.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc:
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
PeiSerialPortLibSpiFlash is currently used for early boot closed
chassis debug on production systems such as the System 76 Galago Pro
laptop. This change moves the library to KabylakeOpenBoardPkg from
ClevoOpenBoardPkg since the Clevo
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
Adds the board ID as a field in global NVS (BDID) to allow ACPI code
to take conditional actions based on the active board.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Ankit Sinha
Cc: Jeremy Soller
Signed-off-by: Michael Kubacki
---
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
Adds the modules used for System 76 Galago Pro 3 board support.
This override should be removed in a future cleanup change. That is
outside the scope of this change which is to move the contents from
ClevoOpenBoardPkg/N1xxWU to
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
The flash map currently in KabylakeOpenBoardPkg is only
applicable to the KabylakeRvp3 board. This change moves
the flash map to that board directory to prepare for other
boards to reside in the package.
Cc: Chasel Chiu
Cc: Nate DeSimone
This patch series moves the N1xxWU board contents currently in ClevoOpenBoardPkg
to KabylakeOpenBoardPkg. The actual systems being tested are System 76 Galago
Pro
laptops so the board itself is renamed from "N1xxWU" to"GalagoPro3". The system
models supported are the galp2 (Kaby Lake) and galp3
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
* Adds files required to build the GalagoPro3 board to the board
directory.
* Updates KabylakeOpenBoardPkg/OpenBoardPkg.dec to reference
the new GalagoPro3 board directory.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Ankit Sinha
Cc:
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
* Updates maintainers for the System 76 GalagoPro3 board
* Updated Readme.md with System 76 GalagoPro3 board details
* Adds the ability to build the GalagoPro3 board to build.cfg
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Ankit Sinha
Cc:
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
Moves all Kaby Lake board ID definitions into a single header file
so it is easier to maintain the values and include the values
into common package files that need to make decisions based on board
ID.
Cc: Chasel Chiu
Cc: Nate DeSimone
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
To prepare KabylakeOpenBoardPkg for multi-board support, the policy
update libraries should be moved to the individual board directory.
Prevously KabylakeOpenBoardPkg only supported the KabylakeRvp3 board
and the policy update libraries were
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
Moves the Synaptics PS/2 mouse support required for the Galago Pro 3
trackpad to function from the previous location in
ClevoOpenBoardPkg/N1xxWU to the common ASL file in KabylakeOpenBoardPkg.
The board ID is used to determine which PS/2
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
The N1xxWU board contents will be moved to KabylakeOpenBoardPkg
to reduce code duplication between ClevoOpenBoardPkg and
KabylakeOpenBoardPkg.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Ankit Sinha
Cc: Jeremy Soller
Signed-off-by: Michael
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
Adds the Galago Pro 3 board ID header file.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Ankit Sinha
Cc: Jeremy Soller
Signed-off-by: Michael Kubacki
---
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Include/GalagoPro3Id.h | 13
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2207
Remove references to ClevoOpenBoardPkg external to the package
since the package is now removed.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Ankit Sinha
Cc: Jeremy Soller
Signed-off-by: Michael Kubacki
---
Maintainers.txt | 5
On 09/23/19 17:08, Philippe Mathieu-Daudé wrote:
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>> The last parameter of ReserveResourceInGcd() is "ImageHandle", forwarded
>> in turn to gDS->AllocateMemorySpace() or gDS->AllocateIoSpace() as "owner"
>> image handle.
>>
>> But BlDxeEntryPoint() passes
On 09/23/19 13:45, Philippe Mathieu-Daudé wrote:
> On 9/17/19 9:49 PM, Laszlo Ersek wrote:
>> The HiiConstructConfigHdr() function takes the "DriverHandle" parameter in
>> order to fetch the device path from it, and then turn the device path into
>> PATH routing information.
>>
>> The
Hi Liming,
On 09/24/19 03:19, Liming Gao wrote:
> ShellBinPkg is generated for each edk2 stable tag release.
>
> Cc: Andrew Fish
> Cc: Laszlo Ersek
> Cc: Leif Lindholm
> Cc: Michael D Kinney
> Signed-off-by: Liming Gao
> ---
> Maintainers.txt | 13 ++---
> 1 file changed, 6
From: Marvin Haeuser
Catch WM mouse events and expose them via the SimplePointer protocol.
Cc: Jordan Justen
Cc: Andrew Fish
Cc: Ray Ni
Signed-off-by: Marvin Haeuser
---
EmulatorPkg/Win/Host/WinGopInput.c | 25 ++--
EmulatorPkg/Win/Host/WinGopScreen.c | 41
From: Marvin Haeuser
Currently, SourceX is not considered in the BufferToVideo operation
when the 8-bit pixel format is used. Correctly add the resulting
offset to prevent image corruption.
Cc: Jian J Wang
Cc: Hao A Wu
Signed-off-by: Marvin Haeuser
---
On 09/24/19 12:41, Philippe Mathieu-Daudé wrote:
> Hi Liming,
>
> On 9/24/19 3:19 AM, Liming Gao wrote:
>> ShellBinPkg is generated for each edk2 stable tag release.
>>
>> Cc: Andrew Fish
>> Cc: Laszlo Ersek
>> Cc: Leif Lindholm
>> Cc: Michael D Kinney
>> Signed-off-by: Liming Gao
>> ---
>>
On 09/20/19 12:24, Leif Lindholm wrote:
>
> On Fri, Sep 20, 2019 at 08:13:36AM +0200, Laszlo Ersek wrote:
>> On 09/19/19 20:06, Leif Lindholm wrote:
>>> Cc: Jordan Justen
>>> Cc: Laszlo Ersek
>>> Cc: Ard Biesheuvel
>>> Cc: Anthony Perard
>>> Cc: Julien Grall
>>> Cc: David Woodhouse
>>>
On 9/24/19 5:05 PM, Liming Gao wrote:
> EBC compiler doesn't support C11 static_assert macro.
> So, define STATIC_ASSERT as empty to pass EBC arch build.
> STATIC_ASSERT macro is introduced @204ae9da230ecbf0910c21acac7aa5d5e8cbb8d0
>
> Cc: Michael D Kinney
> Signed-off-by: Liming Gao
> ---
>
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The ShellCommandRunConnect() function passes EFI_HANDLE -- (VOID*) --
> objects to ConvertAndConnectControllers(), and
> ConvertAndConnectControllers() passes those to gBS->OpenProtocol().
>
> Accordingly, ConvertAndConnectControllers() should specify
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> Clean up two issues around FindFileEx():
>
> - The "AprioriFile" parameter's type differs between the function
> declaration and the function definition. The correct type is
> (EFI_PEI_FILE_HANDLE*).
>
> - "FfsFileHeader" has type
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> The HandleProtocol() boot service takes an EFI_HANDLE, not an
> (EFI_HANDLE*). Remove the bogus cast in the
> InternalImageHandleToFvHandle() function.
>
> This is a semantic cleanup; there is no change in behavior.
>
> Cc: Liming Gao
> Cc: Michael D
On 9/24/19 5:17 PM, Gao, Liming wrote:
>> -Original Message-
>> From: Philippe Mathieu-Daudé
>> Sent: Tuesday, September 24, 2019 11:13 PM
>> To: Gao, Liming ; devel@edk2.groups.io; Leif Lindholm
>>
>> Cc: Andrew Fish ; Laszlo Ersek ; Kinney,
>> Michael D
>> Subject: Re: [edk2-devel]
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: Tuesday, September 24, 2019 11:13 PM
> To: Gao, Liming ; devel@edk2.groups.io; Leif Lindholm
>
> Cc: Andrew Fish ; Laszlo Ersek ; Kinney,
> Michael D
> Subject: Re: [edk2-devel] [Patch] Maintainers.txt: Move ShellBin
On 9/24/19 5:08 PM, Gao, Liming wrote:
> Philipe:
>
>> -Original Message-
>> From: devel@edk2.groups.io On Behalf Of Philippe
>> Mathieu-Daudé
>> Sent: Tuesday, September 24, 2019 6:41 PM
>> To: devel@edk2.groups.io; Gao, Liming ; Leif Lindholm
>>
>> Cc: Andrew Fish ; Laszlo Ersek ;
Philipe:
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Philippe
> Mathieu-Daudé
> Sent: Tuesday, September 24, 2019 6:41 PM
> To: devel@edk2.groups.io; Gao, Liming ; Leif Lindholm
>
> Cc: Andrew Fish ; Laszlo Ersek ; Kinney,
> Michael D
> Subject: Re: [edk2-devel]
EBC compiler doesn't support C11 static_assert macro.
So, define STATIC_ASSERT as empty to pass EBC arch build.
STATIC_ASSERT macro is introduced @204ae9da230ecbf0910c21acac7aa5d5e8cbb8d0
Cc: Michael D Kinney
Signed-off-by: Liming Gao
---
MdePkg/Include/Base.h | 5 -
1 file changed, 4
*Reminder:* TianoCore Design / Bug Triage - EMEA
*When:* Wednesday, 25 September 2019, 8:00am to 9:00am, (GMT-07:00) America/Los
Angeles
*Where:* https://zoom.us/j/695893389
View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=503243 )
*Organizer:* Stephano Cetola
On 9/24/19 6:59 AM, Laszlo Ersek wrote:
> On 09/19/19 21:52, Lendacky, Thomas wrote:
>> From: Tom Lendacky
>>
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
>>
>> When SEV-ES is active, then SEV is also active. Add support to the SEV
>> initialization function to also check for SEV-ES
On 9/23/19 8:55 PM, Dong, Eric wrote:
> Hi Tom,
Hi Eric,
>
> Thanks for you to contribute such a big changes. Seems like this is a big
> changes for current code, can you help to do a design review in TianoCore
> Design Meeting? It will be helpful for us to understand the code change and
>
Mike:
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Michael D
> Kinney
> Sent: Tuesday, September 24, 2019 1:44 AM
> To: Sean Brogan ; devel@edk2.groups.io;
> r...@edk2.groups.io; Kinney, Michael D
>
> Cc: Bret Barkelew
> Subject: Re: [edk2-devel] [RFC] EDK II
On 09/24/19 15:42, Laszlo Ersek wrote:
> On 09/19/19 21:52, Lendacky, Thomas wrote:
>> +mov esp, SEV_TOP_OF_STACK
> (3) Do we have an estimate how much stack we need? This would be a
> constraint on PcdOvmfSecPeiTempRamSize. The limit would be nice to
> document (perhaps in a comment
Nice catch. Moving the check into the if conditional section would avoid the
additional check when the status is EFI_SUCCESS.
Reviewed-by: Zhichao Gao
Thanks,
Zhichao
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Philippe Mathieu-Daudé
On 09/19/19 21:52, Lendacky, Thomas wrote:
> From: Tom Lendacky
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
>
> During BSP startup, the reset vector code will issue a CPUID instruction
> while in 32-bit mode. When running as an SEV-ES guest, this will trigger
> a #VC exception.
On 9/24/19 3:16 PM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
>
> But if the caller
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, September 24, 2019 9:15 PM
> To: Wu, Hao A; Marvin Häuser; devel@edk2.groups.io; Ni, Ray
> Cc: Wang, Jian J
> Subject: RE: [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly consider
> SourceX
>
> I have just viewed a same patch of
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
v2:
Just enahnce the code error handling logic in patch 3.
Other patches are the same and pick up the Acked-by and Reviewed-by in other
patches.
v2:
(1) Just separate the patch in MdeModulePkg into module level, the changes in
I have just viewed a same patch of this issue. See
https://edk2.groups.io/g/devel/topic/34168097#47297.
The two patches are doing the same thing.
Thanks,
Zhichao
> -Original Message-
> From: Wu, Hao A
> Sent: Tuesday, September 24, 2019 9:02 PM
> To: Marvin Häuser ;
> -Original Message-
> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> Sent: Tuesday, September 24, 2019 8:46 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A
> Subject: [PATCH] MdeModulePkg/FrameBufferBltLib: Correctly consider
> SourceX
>
> From: Marvin Haeuser
>
On Mon, Sep 23, 2019 at 8:25 PM Feng, Bob C wrote:
>
> Hi Dann,
>
> Thanks for raising this issue.
>
> Would you provide the static_library_files.list file, so that I can have a
> check?
Hi Bob,
Sure - it occurs to me that bugzilla might be a better place to
share this material, so I've
On 20/09/19 11:28, Laszlo Ersek wrote:
>> On QEMU side, we can drop black-hole approach and allocate
>> dedicated SMRAM region, which explicitly gets mapped into
>> RAM address space and after SMI hanlder initialization, gets
>> unmapped (locked). So that SMRAM would be accessible only
>> from
On 09/19/19 21:52, Lendacky, Thomas wrote:
> From: Tom Lendacky
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
>
> When SEV-ES is active, then SEV is also active. Add support to the SEV
> initialization function to also check for SEV-ES being active. If SEV-ES
> is active, set the
On 09/19/19 21:52, Lendacky, Thomas wrote:
> From: Tom Lendacky
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
>
> Create a function that can be used to determine if the VM is running
> as an SEV-ES guest.
>
> Cc: Jordan Justen
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
>
On 9/24/19 1:34 PM, Laszlo Ersek wrote:
> In a subsequent patch, we'll introduce new DRAM controller macros in
> "Q35MchIch9.h". Their names are too long for the currently available
> vertical whitespace, so increase the latter first.
>
> There is no functional change in this patch ("git show -b"
On 9/24/19 1:34 PM, Laszlo Ersek wrote:
> Before adding another SMM-related, and therefore Q35-only, dynamically
> detectable feature, extract the current board type check from
> Q35TsegMbytesInitialization() to a standalone function.
>
> Cc: Ard Biesheuvel
> Cc: Boris Ostrovsky
> Cc: Brijesh
When OVMF runs in a SEV guest, the initial SMM Save State Map is
(1) allocated as EfiBootServicesData type memory in OvmfPkg/PlatformPei,
function AmdSevInitialize(), for preventing unintended information
sharing with the hypervisor;
(2) decrypted in AmdSevDxe;
(3) re-encrypted in
Now that the SMRAM at the default SMBASE is honored everywhere necessary,
implement the actual detection. The (simple) steps are described in
previous patch "OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register
macros".
Cc: Ard Biesheuvel
Cc: Boris Ostrovsky
Cc: Brijesh Singh
Cc: Igor
The permanent PEI RAM that is published on the normal boot path starts
strictly above MEMFD_BASE_ADDRESS (8 MB -- see the FDF files), regardless
of whether PEI decompression will be necessary on S3 resume due to
SMM_REQUIRE. Therefore the normal boot permanent PEI RAM never overlaps
with the SMRAM
Before adding another SMM-related, and therefore Q35-only, dynamically
detectable feature, extract the current board type check from
Q35TsegMbytesInitialization() to a standalone function.
Cc: Ard Biesheuvel
Cc: Boris Ostrovsky
Cc: Brijesh Singh
Cc: Igor Mammedov
Cc: Jiewen Yao
Cc: Joao M
For supporting VCPU hotplug with SMM enabled/required, QEMU offers the
(dynamically detectable) feature called "SMRAM at default SMBASE". When
the feature is enabled, the firmware can lock down the 128 KB range
starting at the default SMBASE; that is, the [0x3_, 0x4_]
interval. The goal is
During normal boot, when EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed
by platform BDS, the SMM IPL locks SMRAM (TSEG) through
EFI_SMM_ACCESS2_PROTOCOL.Lock(). See SmmIplReadyToLockEventNotify() in
"MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c".
During S3 resume, S3Resume2Pei locks SMRAM (TSEG)
The 128KB SMRAM at the default SMBASE will be used for protecting the
initial SMI handler for hot-plugged VCPUs. After platform reset, the SMRAM
in question is open (and looks just like RAM). When BDS signals
EFI_DXE_MM_READY_TO_LOCK_PROTOCOL (and so TSEG is locked down), we're
going to lock the
Introduce the Q35SmramAtDefaultSmbaseInitialization() function for
detecting the "SMRAM at default SMBASE" feature.
For now, the function is only a skeleton, so that we can gradually build
upon the result while the result is hard-coded as FALSE. The actual
detection will occur in a later patch.
In Intel datasheet 316966-002 (the "q35 spec"), Table 5-1 "DRAM Controller
Register Address Map (D0:F0)" leaves the byte register at config space
offset 0x9C unused.
On QEMU's Q35 board, for detecting the "SMRAM at default SMBASE" feature,
firmware is expected to write MCH_DEFAULT_SMBASE_QUERY
In a subsequent patch, we'll introduce new DRAM controller macros in
"Q35MchIch9.h". Their names are too long for the currently available
vertical whitespace, so increase the latter first.
There is no functional change in this patch ("git show -b" displays
nothing).
Cc: Ard Biesheuvel
Cc: Boris
Ref:https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Repo: https://github.com/lersek/edk2.git
Branch: smram_at_default_smbase_bz_1512_wave_1
This is the firmware-side patch series for the QEMU feature that Igor is
proposing in
[Qemu-devel] [PATCH 0/2]
q35: mch: allow to lock down
On Mon, 23 Sep 2019 20:35:02 +0200
"Laszlo Ersek" wrote:
> On 09/20/19 11:28, Laszlo Ersek wrote:
> > On 09/20/19 10:28, Igor Mammedov wrote:
> >> On Thu, 19 Sep 2019 19:02:07 +0200
> >> "Laszlo Ersek" wrote:
> >>
> >>> Hi Igor,
> >>>
> >>> (+Brijesh)
> >>>
> >>> long-ish pondering ahead,
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
> NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
> NULL-check. Fix the type of "SnpHandle".
>
> This patch is a no-op.
>
> Cc: Jiaxin Wu
> Cc: Siyuan Fu
>
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
> the notification handle to have type (VOID*). The notification handle has
> nothing to do with the EFI_HANDLE type.
>
> This change is a semantic fix; functionally, it's a no-op.
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> HiiGetHiiHandles() returns an array of EFI_HII_HANDLEs, not EFI_HANDLEs.
> HiiGetString() takes an EFI_HII_HANDLE, not an EFI_HANDLE.
>
> This change is a no-op in practice; it's a semantic improvement.
>
> Cc: Dandan Bi
> Cc: Eric Dong
> Cc: Hao A Wu
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> - The 2nd parameter of EFI_SERVICE_BINDING_CREATE_CHILD is:
>
> IN OUT EFI_HANDLE *ChildHandle
>
> - The 2nd parameter of EFI_SERVICE_BINDING_DESTROY_CHILD is:
>
> IN EFI_HANDLE ChildHandle
>
> Fix the DestroyChild() call in
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
> the notification handle to have type (VOID*). The notification handle has
> nothing to do with the EFI_HANDLE type.
>
> This change is a semantic fix; functionally, it's a no-op.
On 9/17/19 9:49 PM, Laszlo Ersek wrote:
> GetModuleInfoFromHandle() takes an EFI_HANDLE -- (VOID*) -- as first
> parameter, but InsertFpdtRecord() passes (EFI_HANDLE*) -- (VOID**).
> (VOID**) converts silently to (VOID*), which is why the wrong cast is
> masked.
>
> Note that the *value* that is
Hi Liming,
On 9/24/19 3:19 AM, Liming Gao wrote:
> ShellBinPkg is generated for each edk2 stable tag release.
>
> Cc: Andrew Fish
> Cc: Laszlo Ersek
> Cc: Leif Lindholm
> Cc: Michael D Kinney
> Signed-off-by: Liming Gao
> ---
> Maintainers.txt | 13 ++---
> 1 file changed, 6
On 9/18/19 5:05 AM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
>
> But if the caller
On 9/18/19 5:05 AM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
>
> But if the caller
Hi Dandan,
On 9/18/19 5:05 AM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
>
> But if
On 9/18/19 5:05 AM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
>
> But if the caller
On 9/18/19 5:05 AM, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
>
> But if the caller
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2061
check MediaPresent while MediaPresentSupported is TRUE
sync change from EFI to IHV SimpleNetworkBBTestFunction
Cc: Heinrich Schuchardt
Cc: Supreeth Venkatesh
Cc: Eric Jin
Signed-off-by: xianhui liu
---
Hi Derek,
I took a look at this issue, and add back the -hash functionality in this
branch: https://github.com/shijunjing/edk2/tree/hashcache_v1. The attachment is
the patch based on latest edk2.
The current -hash fix performance is not as good as the edk2-stable201905,
because the
95 matches
Mail list logo
