- Protocol/Legacy8259.h
Cc: Ard Biesheuvel
Cc: Gerd Hoffmann
Cc: Jiewen Yao
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek
---
OvmfPkg/OvmfPkg.dec| 1 -
OvmfPkg/Csm/Include/Protocol/LegacyInterrupt.h | 121
2
://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Csm/Csm16/Csm16.inf | 17 -
OvmfPkg/Csm/Csm16/ReadMe.txt | 12
2 files changed, 29 deletions(-)
diff --git a/OvmfPkg/Csm/Csm16/Csm16.inf b/OvmfPkg/Csm/Csm16/Csm16.inf
deleted file mode
=CSM. Remove those rules as well.)
Cc: Anatol Belski
Cc: Anthony Perard
Cc: Ard Biesheuvel
Cc: Corvin Köhne
Cc: Gerd Hoffmann
Cc: Jianyong Wu
Cc: Jiewen Yao
Cc: Rebecca Cran
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Bhyve/BhyveX64.fdf
cca Cran
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Bhyve/BhyveX64.dsc | 4
OvmfPkg/OvmfPkgIa32.dsc| 4
OvmfPkg/OvmfPkgIa32X64.dsc | 4
OvmfPkg/OvmfPkgX64.dsc | 4
OvmfPkg/OvmfXen.dsc| 4
OvmfPkg/Bhyve/BhyveX64.fdf | 4
c0c2eb0a59 ("OvmfPkg: fix PcdFSBClock",
2022-05-25).
Regression test: verified that the BDS progress bar still advanced at
normal speed in each platform.
Cc: Ard Biesheuvel
Cc: Gerd Hoffmann
Cc: Jiewen Yao
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo
scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiLegacy8259ProtocolGuid
- headers:
- Protocol/Legacy8259.h
Cc: Ard Biesheuvel
Cc: Gerd Hoffmann
Cc: Jiewen Yao
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek
---
OvmfPkg/8254TimerDxe/Timer.uni
With 8254TimerDxe gone, no module in OVMF consumes
gEfiLegacy8259ProtocolGuid; exclude 8259InterruptControllerDxe therefore.
Cc: Ard Biesheuvel
Cc: Gerd Hoffmann
Cc: Jiewen Yao
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek
---
OvmfPkg/OvmfPkgIa32.dsc
Hoffmann
Cc: Jiewen Yao
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek
---
OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni | 16 -
OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni | 14 -
OvmfPkg/8259InterruptControllerDxe/8259.inf
?id=4588
Signed-off-by: Laszlo Ersek
---
OvmfPkg/OvmfPkg.dec | 1 -
OvmfPkg/Include/Protocol/Legacy8259.h | 290
2 files changed, 291 deletions(-)
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 9d326e8143eb..2e9e699aa6ab 100644
--- a/OvmfPkg
Xu
Cc: Tom Lendacky
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek
---
OvmfPkg/OvmfPkg.dec | 26
OvmfPkg/AmdSev/AmdSevX64.dsc | 3 ---
OvmfPkg/IntelTdx/IntelTdxX64.dsc | 3 ---
OvmfPkg/Microvm/MicrovmX64.dsc | 3
https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Bhyve/BhyveX64.dsc | 7 +--
OvmfPkg/IntelTdx/IntelTdxX64.dsc | 3 ---
OvmfPkg/OvmfPkgIa32.dsc | 3 ---
OvmfPkg/OvmfPkgIa32X64.dsc | 3 ---
OvmfPkg/OvmfPkgX64.dsc | 3 ---
OvmfPkg/OvmfXe
es", 2021-07-14). The
commit message is similarly empty.
Laszlo
>
> Thanks,
> Chasel
>
>
>
>> -Original Message-
>> From: devel@edk2.groups.io On Behalf Of Laszlo Ersek
>> Sent: Thursday, November 9, 2023 4:06 AM
>> To: devel@edk2.groups.io
>>
On 11/13/23 04:15, Ni, Ray wrote:
> I provided 4 comments in below, starting with "[Ray".
>
> Sorry for the poor new Outlook that I am not able to put ">" in the
> original email.
>
> Thanks,
> Ray
>
>
>
> (1) I agree that
as not
> committed when I porting LoongArchVirt, my code base is based on
> stable202308, so I don't know you committed a new library, sorry.
Sure, that sometimes happens when a new feature takes long (either to
implement, or to review).
Laszlo
>
>
>
> Thanks,
> Chao
On 11/10/23 07:44, Chao Li wrote:
> Hi Laszlo,
>
> This is a good question, same as the previous email, some ARCH don't
> require running code on memory during PEI phase or other reason can not
> used the MdePkg version, so this pointer will be saved by some register,
> I saw the ArmPkg version al
On 11/10/23 10:46, Gerd Hoffmann wrote:
> On Fri, Nov 10, 2023 at 03:09:47PM +0800, Chao Li wrote:
>> Hi Laszlo,
>>
>> Sorry, I'm not check carefully, it is really **copied**, and we not think
>> the ARM version is not good enough.
>>
>> So, can I move this library to OvmfPkg so other ARCH use it e
On 11/8/23 05:29, Ranbir Singh wrote:
> Hi Mike,
>
> I agree that any manual inspection is sort of a burden, more so when it
> becomes repetitive in the long run.
>
> When I was doing these Coverity checks (Nov-Dec' 2022), I was working in
> Dell and had access to the real systems to check the ex
against Coverity, I
don't know if this patch is worth the churn. :( As I said, this ASSERT()
is one of those few justified ones in edk2 core that can indeed never
fail, IMO.
Laszlo
>
> On Tue, Nov 7, 2023 at 10:18 PM Laszlo Ersek <mailto:ler...@redhat.com>> wrote:
>
On 11/8/23 05:11, Wu, Jiaxin wrote:
> Hi Laszlo,
>
>>>
>>> The patch looks OK to me, but:
>>>
>>> - I would like to test it with CPU hotplug (later, likely under v2), and
>>>
>
> Sure, I can wait the update from you.
>
>>> - I think this should be two patches.
>>>
>>> First, the SmmAddProcessor(
On 11/8/23 02:06, Michael D Kinney wrote:
> Hi Jose,
>
>
>
> 1. This logic needs to move into an AARCH64 specific directory/file.
> Other architectures handle this in other ways.
> 2. There are many places throughout edk2 sources that perform PCI
> config write operations. You are o
Hi Michael,
recently I encountered an uncrustify failure on github.
The reason was that my local uncrustify was *more recent* (73.0.8) than
the one we use in edk2 CI (which is 73.0.3, per the edk2 file
".pytool/Plugin/UncrustifyCheck/uncrustify_ext_dep.yaml").
Updating the version number in the
On 11/9/23 19:08, Michael D Kinney wrote:
> +Ray
>
>
>
> Unless I missed it, I do not see review of the patch series Ray sent
> back in July.
Right, please repost.
Laszlo
>
>
>
> Mike
>
>
>
> *From:* devel@edk2.groups.io *On Behalf Of *Aaron
> Young via groups.io
> *Sent:* Thursday,
On 11/9/23 11:39, Hamit Can Karaca wrote:
> Hello,
> I am a young UEFI developer and I am trying to use the functions in
> Tpm2CommandLib to write data to TPM2. I have defined the index that, I
> am going to write data to, using the DefineSpace function. But whenever
> I am trying to use the Tpm2Nv
ce is left alone.
The RISC-V OVMF platform uses "BaseIoLibIntrinsic.inf", but RISC-V
already doesn't (can't) use the IA32/X64 NASM files.
So, surprisingly, the "IoFifo.nasm" files are actually unused,
pre-patch; IA32 and X64 OVMF only uses the "IoFifo
On 11/7/23 16:43, Michael Kubacki wrote:
> The series that makes it easy to run CodeQL locally and have access to
> results from any PR or push to master.
>
> Those that have access can see the results directly in "Code Scanning"
> in the "Security" tab of the edk2 repo. That may be affected in ti
sorry, unfinished thought:
On 11/13/23 14:39, Laszlo Ersek wrote:
> - the "sarif emacs" output seems a bit broken, actually, so it's not usable.
> Consider the following entry from the original JSON file:
>
> }, {
> "ruleId" : "cp
27;t. So technically, the replacement of the protocol
with the HOB should be fine, but for the general case, we should
document somehow that specific fields of the HOB may be invalidated
between HOB production and HOB consumption. If platform code is required
to prevent that (i.e., the platform is
hub.com/tianocore/edk2-test/uefi-sct
> +T: git - https://github.com/tianocore/edk2-test
>
>
> Responsible Disclosure, Reporting Security Issues
Reviewed-by: Laszlo Ersek
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#
Hi Charles,
On 10/26/23 03:05, Charles Hyde wrote:
> From: Charles Hyde
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2861
>
> I believe the attached ConfigRouting.txt patch will resolve bug 2861, plus
> resolve an uninitialized pointer issue in HiiConfigRoutingExportConfig().
> The un
) {
> - PackageId = gSmmCpuPrivate->ProcessorInfo[Index].Location.Package;
> +if (PackageId <
> gSmmCpuPrivate->ProcessorInfo[Index].ExtendedInformation.Location2.Package) {
> + PackageId =
> gSmmCpuPrivate->ProcessorInfo[Index].ExtendedInformation.Location2.Pack
On 11/13/23 16:38, Laszlo Ersek wrote:
> On 11/7/23 03:43, Wu, Jiaxin wrote:
>> Processor extended information is filled when
>> CPU_V2_EXTENDED_TOPOLOGY is set in parameter ProcessorNumber
>> from GetProcessorInfo() (See commit: 1fadd18d).
>>
>> This filed value
On 11/9/23 21:40, Michael D Kinney wrote:
> Hi Ranbir,
>
> A deadloop without even a debug print is not good behavior.
In DEBUG and NOOPT builds, the ASSERT() would fire, hence providing a
debug message.
In RELEASE builds, even if there were a separate DEBUG message, the
DEBUG would be compiled
other
words, the behavior of both snippets is undistinguishable in RELEASE
builds too.
In my opinion, the current patch is right.
Reviewed-by: Laszlo Ersek
To elaborate on that more generally:
Core edk2 code has so consistently and so broadly *abused* and *misused*
ASSERT() for error
x27;s *exactly the reason* for including an ASSERT() in the code!
To remind the reader that a (perhaps non-obvious) predicate always holds
at that location!
So, the argument
ASSERT(X) is unneeded because X always holds
is backwards. You do an ASSERT(X) *because* X always holds, and X is
non-tr
+
>//
>// calculate the pci memory address for host memory address.
>//
> @@ -603,6 +623,15 @@ UsbHcFreeMem (
>//
>ASSERT (Block != NULL);
>
> + if (Block == NULL) {
> +//
> +// Should never be here
> +//
> +DEBUG ((DEBUG_ERROR,
nsfer ring is not allocated.\n"));
>default:
> -DEBUG ((DEBUG_INFO, "XhcInitializeEndpointContext64: Unknown EP
> found, Transfer ring is not allocated.\n"));
> +DEBUG ((
> + DEBUG_INFO,
> + "%a: %a found, Transfer ring is
On 11/13/23 06:47, Yuanhao Xie wrote:
> SMM read save state requires AP must be present.
> This patch aim to avoid the AP not ready for save state check.
>
> Signed-off-by: Zhihao Li
> Cc: Ray Ni
> Cc: Rahul Kumar
> Cc: Gerd Hoffmann
> ---
> UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c | 25 +++
On 11/13/23 06:59, Yuanhao Xie wrote:
> From: Yuanhao Xie
>
> This patch synchronizes the No-Execute bit in the IA32_EFER
> register for the APs before the RestoreVolatileRegisters operation.
>
> The commit 964a4f0, titled "Eliminate the second INIT-SIPI-SIPI
> sequence," replaces the second INIT-
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Cet.nasm | 5 ++-
> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm | 39 +++
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/Cet.nasm | 5 ++-
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm | 40 +++-
> 5 files changed, 7
On 11/13/23 20:07, Pedro Falcato wrote:
> On Mon, Nov 13, 2023 at 11:58 AM Laszlo Ersek wrote:
>>
>> Hi Michael,
>>
>> recently I encountered an uncrustify failure on github.
>>
>> The reason was that my local uncrustify was *more recent* (73.0.8) than
On 11/13/23 22:33, Pedro Falcato wrote:
> On Mon, Nov 13, 2023 at 8:37 PM Rebecca Cran wrote:
>>
>> On 11/13/2023 1:08 PM, Michael Kubacki wrote:
>>> Yes. I just did it. It is relatively minor and impacts expected code
>>> areas.
>>>
>>> https://github.com/tianocore/edk2/pull/5043/files
>>
>>
>> C
+Jiewen (I seem to remember Jiewen co-authored a whitepaper on edk2
variables; I could be wrong)
one more comment below:
On 11/14/23 09:23, Gao wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4597
>
> When creating a new variable, skip marking VAR_HEADER_VALID_ONLY so that
> variable
Small patch, but I have several comments :)
On 11/14/23 03:08, Zhiguang Liu wrote:
> Currently, if BSP election is not enabled, will use Core0 as SMM BSP,
> however, Core0 does not always have the highest performance core.
> So, we can used NonSmm BSP as default BSP.
(1) Please consider mentionin
On 11/14/23 17:53, Laszlo Ersek wrote:
> Second, "SMM_DISPATCHER_MP_SYNC_DATA.BspIndex" has type "(volatile)
> UINT32", but WhoAmI() writes an UINTN. On IA32, you're going to corrupt
> memory.
sorry, it's on X64 where you are going to corrupt memory (the
On 11/14/23 16:12, Rebecca Cran wrote:
> On 11/14/2023 7:51 AM, Laszlo Ersek via groups.io wrote:
>
>> Funnily enough, my stance is quite the opposite. I happen to disagree
>> with some patterns that uncrustify enforces, but I'm thankful that at
>> any given state of
On 11/14/23 17:11, Ranbir Singh wrote:
>
>
> On Mon, Nov 13, 2023 at 10:03 PM Laszlo Ersek <mailto:ler...@redhat.com>> wrote:
>
> On 11/9/23 18:39, Ranbir Singh wrote:
> > From: Ranbir Singh
> >
> > The function SubmitResources has a
On 11/14/23 17:34, Ranbir Singh wrote:
> Though you already gave R-b, the return statement needs to be added to
> explicitly and completely rule out ARRAY_OVERRUN issue by static
> analysis tools.
>
> ASSERT (Index < TypeMax);
> +
> + if (Index == TypeMax) {
> +
On 11/14/23 17:21, Kinney, Michael D wrote:
> Hi Ranbir,
>
>
>
> First I want to recognize your efforts to collect Coverity issues and
> propose changes to address
> them.
>
> I still disagree with adding CpuDealLoop() for any static analysis issues.
>
> There have been previous discussions a
On 11/14/23 17:53, Ranbir Singh wrote:
> Generally speaking, there now seems to be different views coming from
> you and Laszlo.
Yes.
> We might have to wait for some sort of agreement to be
> reached.
I don't insist on CpuDeadLoop() *specifically*. Only the following two
generic points matter
s.
>>
>> We also have to evaluate if a return error status with a DEBUG_ERROR
>> message would be a better
>>
>> choice than an ASSERT() that can be filtered out by build options.
>>
>> Best regards,
>>
>> Mike
>>
>> *From:* devel@edk2
indows too?
Laszlo
>
> *From:* Sheng, W
> *Sent:* Monday, November 13, 2023 2:22 PM
> *To:* devel@edk2.groups.io
> *Cc:* Dong, Eric ; Ni, Ray ;
> Laszlo Ersek ; Wu, Jiaxin ; Tan,
> Dun
> *Subject:* [
On 11/15/23 05:12, Sheng Wei wrote:
> The macro is used in file LongJump.nasm and SetJump.nasm.
>
> Signed-off-by: Sheng Wei
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Wu Jiaxin
> Cc: Tan Dun
> ---
> MdePkg/Library/BaseLib/Ia32/LongJump.nasm | 3
On 11/15/23 05:12, Sheng Wei wrote:
> Signed-off-by: Sheng Wei
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Wu Jiaxin
> Cc: Tan Dun
> Reviewed-by: Laszlo Ersek
> ---
> MdePkg/Include/Cet.inc | 26 ++
> 1 file changed, 26 inser
Hi Chasel,
On 11/10/23 02:13, Chiu, Chasel wrote:
>
> Hi Laszlo,
>
> I verified and encountered build failure as some files still consuming
> definitions from LegacyBiosMpTable.h, for example:
> https://github.com/tianocore/edk2-platforms/blob/899a9dc97cd54690513380ad01ee8b2609dbefd5/Platform/I
ype": "nuget",
>"name": "mu-uncrustify-release",
>"source":
> "https://pkgs.dev.azure.com/projectmu/Uncrustify/_packaging/mu_uncrustify/nuget/v3/index.json";,
> - "version": "73.0.3",
> + "version": &
)) /
> FixedPcdGet32 (PcdEmuFirmwareBlockSize),
> FixedPcdGet32 (PcdEmuFirmwareBlockSize),
> }
>}
Reviewed-by: Laszlo Ersek
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111263): https://edk2.groups.io/g/devel/mes
aInfo[] = {
>{
> {
>(FixedPcdGet32 (PcdFlashNvStorageVariableSize) +
> - FixedPcdGet32 (PcdFlashNvStorageFtwWorkingSize) +
> - FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize) +
> - FixedPcdGet32 (PcdOvmfFlashNvStorageEventLogSize)) /
> +
On 11/15/23 01:35, Michael Kubacki wrote:
> On 11/13/2023 8:42 AM, Laszlo Ersek wrote:
>> sorry, unfinished thought:
>>
>> On 11/13/23 14:39, Laszlo Ersek wrote:
>>
>>> - the "sarif emacs" output seems a bit broken, actually, so it's not
>>
Hi Chao,
On 11/15/23 04:21, Chao Li wrote:
> Well, let's discuss the ARM version name once moved.
>
> I have two plans:
>
> *Plan A:*
>
> Merge the ARM version into PlatformBootmanagerLib and modify the inf
> file to separate X64 and other ARCH, like be:
>
> [Sources.Common]
>
> QemuKerne
On 11/15/23 13:03, Hamit Can Karaca wrote:
> Thanks for your Laszlo,
>
> I am using the functions that are available in EDK2 TpmCommandLib. I am
> not sure where I fail because all the structs that I use are those which
> are given in EDK2. I will add my code below. It would be very nice If
> you
gt; patch also fixes the existing check in GetProcessorLocationByApicId() to
> be in line with the spec by looking at bits 15:0. The comments are
> updated with a quote from the Intel SDM.
>
> Cc: Laszlo Ersek
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Rahul Kumar
> Cc: Gerd Hoffmann
> Cc:
Biesheuvel
Cc: Gerd Hoffmann
Cc: Jiewen Yao
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Rahul Kumar
Cc: Ray Ni
Cc: Sami Mujawar
Thanks,
Laszlo
Laszlo Ersek (3):
Maintainers.txt: add Laszlo Ersek as an ArmVirtPkg maintainer
Maintainers.txt: add Laszlo Ersek as an OvmfPkg maintainer
Mai
/VirtioPciDeviceDxe/
OvmfPkg/VirtioRngDxe/
OvmfPkg/VirtioScsiDxe/
Cc: Andrew Fish
Cc: Ard Biesheuvel
Cc: Gerd Hoffmann
Cc: Jiewen Yao
Cc: Leif Lindholm
Cc: Michael D Kinney
Signed-off-by: Laszlo Ersek
---
Maintainers.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Maintainers.txt b
: Sami Mujawar
Signed-off-by: Laszlo Ersek
---
Maintainers.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Maintainers.txt b/Maintainers.txt
index 7c0b4cb58cfd..da174fbdd1bc 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -151,6 +151,7 @@ ArmVirtPkg
F: ArmVirtPkg/
W: https
UefiCpuPkg/UefiCpuPkg.dsc
UefiCpuPkg/Universal/Acpi/S3Resume2Pei/
Cc: Andrew Fish
Cc: Gerd Hoffmann
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Rahul Kumar
Cc: Ray Ni
Signed-off-by: Laszlo Ersek
---
Maintainers.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Maintainers.txt b
(-announce)
On 11/13/23 15:57, gaoliming via groups.io wrote:
> Hi, all
>
> Today, we enter into Hard Feature Freeze phase until edk2-stable202311 tag
>
> is created at 2023-11-24. In this phase, there is no feature to be pushed.
>
> The critical bug fix or the approved change is still allowe
On 11/17/23 09:07, Dhaval Sharma wrote:
> Hi,
> I wanted to revisit this thread and I am maintaining the context as
> there are a lot of details already mentioned here regarding EFI_MEMORY_SP.
> Other than what has been addressed here, we also would like to have an
> option in edk2 to *avoid* using
Lib.h"?
A number of structures in "UefiCpuPkg/Library/MpInitLib/MpLib.h"
document whether they are to be used by assembly code vs. C code (vs.
both), but CPU_MP_DATA doesn't seem to have such comments.
For the current patch:
Reviewed-by: Laszlo Ersek
Thanks!
Laszlo
-=-
On 11/17/23 03:15, Yoshinoya wrote:
> Hi,
> I find there is a PrmPkg in udk source code.
> Based on its Readme.md, its goal is to offload smm code to sci os
> mechanisms.
>
> So, is there any actual use case on real platform now?
>
> It seems it's just a conceptional prototype.
It's way too big
On 11/16/23 09:29, Pedro Falcato wrote:
> On Tue, Nov 14, 2023 at 3:01 PM Laszlo Ersek wrote:
>>
>> On 11/13/23 22:33, Pedro Falcato wrote:
>>> On Mon, Nov 13, 2023 at 8:37 PM Rebecca Cran wrote:
>>>>
>>>> On 11/13/2023 1:08 PM, Michael Kubacki w
On 11/15/23 23:12, Igor Kulchytskyy via groups.io wrote:
> Igor Kulchytskyy (2):
> RedfishPkg: RedfishDiscoverDxe: Fix issue if IPv4 installed after
> RestEx
> RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow
>
> .../RedfishDiscoverDxe/RedfishDiscoverDxe.c | 225 ++
(+Liming +Mike)
On 11/16/23 10:01, Gerd Hoffmann wrote:
> On Wed, Nov 15, 2023 at 11:51:53AM -0600, Michael Roth wrote:
>> The struct used for GHCB-based page-state change requests uses a 40-bit
>> bit-field for the GFN, which is shifted by PAGE_SHIFT to generate a
>> 64-bit address. However, anyt
On 11/15/23 04:19, Ashish Singhal via groups.io wrote:
> Just like CPU _UID, ETE UID also needs to be unique so
> use AcpiProcessorUid instead of CpuName
>
> Signed-off-by: Ashish Singhal
> ---
> .../Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c | 5 -
> 1 file changed, 4 insertio
On 11/17/23 13:49, CrossedCarpet wrote:
> Steps to reproduce:
> - download and setup edk2
> - run:
> build -a X64 -b DEBUG -t GCC -p NetworkPkg/NetworkPkg.dsc
>
> Get the error:
> build.py...
> /.../edk2/NetworkPkg/NetworkPkg.dsc(...): error 4000: Instance of
> library class [SynchronizationLib] i
kg/Bhyve/PlatformPei/Platform.c
> +++ b/OvmfPkg/Bhyve/PlatformPei/Platform.c
> @@ -153,8 +153,8 @@ MemMapInitialization (
>UINT64 PciIoSize;
>RETURN_STATUS PcdStatus;
>
> - PciIoBase = 0xC000;
> - PciIoSize = 0x4000;
> + PciIoBase = 0x2000;
> + PciIoSize = 0xE000;
&g
onsuming MpService Protocol.
> So move this HOB definition to UefiCpuPkg.
>
> Signed-off-by: Dun Tan
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Rahul Kumar
> Cc: Gerd Hoffmann
> Cc: Laszlo Ersek
> ---
> UefiCpuPkg/Include/Guid/MpInformation.h | 39
> ++
On 11/17/23 17:37, Ashish Singhal wrote:
>
>
>
> *From:* Laszlo Ersek
> *Sent:* Friday, November 17, 2023 2:20 AM
> *To:* devel@edk2.groups.io ; Ashish Singhal
> ; quic_llind...@quicinc.com
> ; a
On 11/16/23 02:30, Ni, Ray wrote:
> I cannot remember if CPUID.0B and CPUID.1F return the same value for
> package ID.
>
> And I am not sure about the benefit if we get the package id from location2.
Isn't the benefit that Location2 / CPUID leaf 1F is fully specified,
while leaf 0B isn't? From th
On 11/17/23 12:42, Gerd Hoffmann wrote:
> On Fri, Nov 17, 2023 at 10:16:10AM +0100, Laszlo Ersek wrote:
>> (+Liming +Mike)
>>
>> On 11/16/23 10:01, Gerd Hoffmann wrote:
>>> On Wed, Nov 15, 2023 at 11:51:53AM -0600, Michael Roth wrote:
>>>> The struct used
copies-harder
this is a nearly identical copy of
"ArmVirtPkg/PlatformCI/KvmToolBuild.py", the only difference is:
-DscName = os.path.join("ArmVirtPkg", "ArmVirtKvmTool.dsc")
+DscName = os.path.join("ArmVirtPkg", "ArmVirtCloudHv.dsc")
It m
On 11/17/23 18:50, Chiu, Chasel wrote:
>
> Hi Dhaval,
>
> Just a small feedback,
> the only difference will be TableToInstall between XDsdt and Dsdt, could we
> optimize the code flow to reduce duplicate lines?
since a v3 is being requested, let me ask for even more:
- can we specify the preci
those drivers,
with many thanks.
Cc: Aaron Young
Cc: Andrew Fish
Cc: Ard Biesheuvel
Cc: Gerd Hoffmann
Cc: Jiewen Yao
Cc: Leif Lindholm
Cc: Michael D Kinney
Signed-off-by: Laszlo Ersek
---
Notes:
Aaron, can you please confirm that your github user ID is indeed
"ajyoung-oracle"
g Liu
> Cc: Leif Lindholm
> Cc: Ard Biesheuvel
> Cc: Sami Mujawar
> Cc: Laszlo Ersek
> Cc: Sunil V L
> Signed-off-by: Chao Li
> ---
> .../Library/PeiServicesTablePointerLib.h | 37 +++-
> .../PeiServicesTablePointer.c
y 2023), and literally nobody commented in edk2-rfc or edk2-devel.
That's too bad, my apologies. The project has been facing challenges
with timely reviews.
Laszlo
>
> Chip
>
>
> -Original Message- From: Laszlo Ersek
> Sent: Monday, November 13, 2023 9:59 AM
>
like a software
usability construct ("avoid allocating for ...").
But, I truly don't know. I guess I was only trying to gauge if I could
be a useful reviewer for this series; probably not.
Thanks!
Laszlo
>
> On Fri, Nov 17, 2023 at 1:55 PM Laszlo Ersek <mailto:ler...@re
---------
> *From:* Laszlo Ersek
> *Sent:* 17 November 2023 16:06
> *To:* devel@edk2.groups.io ;
> crossedcar...@hotmail.com
> *Cc:* Liming Gao (Byosoft address)
> *Subject:* Re: [edk2-devel] [Bug] Building NetworkPkg fails due to
> mis
*populating* Location2 in the
SMM-add-processor protocol member function (upon CPU hotplug). So, FWIW,
I'm fine if the last patch in the series gets dropped.
Thanks
Laszlo
>
>
>
> Thanks,
>
> Jiaxin
>
>
>
> *From:* Ni, Ray
> *Sent:* Monday, Novembe
On 11/21/23 03:07, Page Chen via groups.io wrote:
> begining -> beginning
> Cabability -> Capability
> CHNAGED -> CHANGED
> compatability -> compatibility
> concident -> coincident
> correspoding -> corresponding
> defered -> deferred
> Dispacher -> Dispatcher
> execuing -> executing
> exhausive ->
Adding Sean
Laszlo
On 11/19/23 23:43, ryderkeys via groups.io wrote:
> Hi all,
>
> I am trying to build EDK2 from most recent Github (namely, EmulatorPkg) with
> the new Stuart build system on Windows 10 22H2 64 bit with VS 2019. I'm
> getting the following error which directed me to this mail
On 11/16/23 07:16, Daniel Nguyen wrote:
> Signed-off-by: Daniel Nguyen
> ---
> .../UefiShellLevel2CommandsLib/Reset.c| 43 +++
> 1 file changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Reset.c
> b/ShellPkg/Library/Ue
On 11/16/23 04:46, Jackie Lien (Temp) via groups.io wrote:
> Hi team,
>
> Please help with the build error in BOOT.MXF.1.1.1. The command and log
> are listed below.
>
>
>
> Sync & build command:
>
> 1. python sync_crm.py BOOT.MXF.1.1.1-00175-Olympic-1
> 2. copy manifest to my local sync (c
On 11/20/23 04:57, Ranbir Singh wrote:
>
>
> On Wed, Nov 15, 2023 at 3:20 PM Laszlo Ersek <mailto:ler...@redhat.com>> wrote:
>
> On 11/14/23 17:21, Kinney, Michael D wrote:
> > Hi Ranbir,
> >
> >
> >
> > Firs
On 11/20/23 08:55, Gerd Hoffmann wrote:
> On Fri, Nov 17, 2023 at 10:39:13PM +0100, Laszlo Ersek wrote:
>> On 11/17/23 12:42, Gerd Hoffmann wrote:
>>> On Fri, Nov 17, 2023 at 10:16:10AM +0100, Laszlo Ersek wrote:
>>>> (+Liming +Mike)
>>>>
>>>>
>
> Cc: Ray Ni
> Cc: Rahul Kumar
> Cc: Gerd Hoffmann
> Cc: Laszlo Ersek
> Signed-off-by: Zhiguang Liu
> ---
> UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
>
On 11/20/23 09:30, Xu, Wei6 wrote:
> Defer the dispatch of the remaining MM drivers once the CPU driver has
> been dispatched.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4599
>
> In MmDispatcher, return immediately if the MM Entry Point was registered.
> Then the MM IPL will reinvoke t
On 11/17/23 11:00, Chao Li wrote:
> Add the LoongArch64 CPU Timer library, using CPUCFG 0x4 and 0x5 for
> Stable Counter frequency.
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
>
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Rahul Kumar
> Cc: Gerd Hoffmann
> Signed-off-by: Chao Li
> ---
On 11/22/23 17:12, Laszlo Ersek wrote:
> On 11/17/23 11:00, Chao Li wrote:
>> +
>> + if (!BaseFreq || !ClockMultiplier || !ClockDivide) {
>
> (13) The edk2 coding style does not like scalar types *other* than
> BOOLEAN to be used in logical context. Please rewrite a
o
> DXE.
>
> Signed-off-by: Yuanhao Xie
> Cc: Laszlo Ersek ler...@redhat.com
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Rahul Kumar
> Cc: Gerd Hoffmann
> ---
> UefiCpuPkg/Library/MpInitLib/MpEqu.inc | 2 ++
> UefiCpuPkg/Library/MpInitLib/MpLib.h | 13 +++--
&
> Sent: Tuesday, November 21, 2023 3:03 PM
>> To: devel@edk2.groups.io
>> Cc: Dong, Eric ; Ni, Ray ; Laszlo
>> Ersek ; Wu, Jiaxin ; Tan, Dun
>>
>> Subject: [PATCH v6 1/6] MdePkg: Add macro definitions for CET feature for
>> NASM files.
>>
>> Signed-off
his patch is aimed at facilitating a more
> straightforward review, with the ultimate goal of eliminating the
> microcode loading functionality for the second time Mp initialization.
>
> Cc: Ray Ni
> Cc: Eric Dong
> Cc: Rahul Kumar
> Cc: Tom Lendacky
> Cc:
401 - 500 of 4419 matches
Mail list logo
