Felix, I remember you mentioned to me about the usage of SMI handler
unregistering itself.
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Liu, Zhiguang
> Sent: Wednesday, January 24, 2024 12:03 PM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Liming Gao
> ; Wu, Jiaxin
Merged: https://github.com/tianocore/edk2/pull/5296
> -Original Message-
> From: Kinney, Michael D
> Sent: Tuesday, January 23, 2024 9:36 PM
> To: devel@edk2.groups.io; jbra...@nvidia.com
> Cc: gaolim...@byosoft.com.cn; Liu, Zhiguang ;
> Kinney, Michael D
> Subject: RE: [edk2-devel] [PA
On Wed, Jan 24, 2024 at 5:20 AM Doug Flick via groups.io
wrote:
>
> The security patches contained in this series with the exception of
> "MdePkg/Test: Add gRT_GetTime Google Test Mock" and
> "NetworkPkg: : Adds a SecurityFix.yaml file" have been reviewed
> during GHSA-hc6x-cw6p-gj7h infosec revie
> +//
> +// Number of self-tests to perform.
> +//
> +#define NUMBER_OF_SELF_TESTS \
> + (FixedPcdGet32 (PcdNestedInterruptNumberOfSelfTests))
1. can we avoid defining a PCD? I do not see a need that each platform needs
to use a different count. How about just define it as 1?
> +
> +STATIC
> +VO
Thank you for adding the self-test code!
Thanks,
Ray
> -Original Message-
> From: Ni, Ray
> Sent: Wednesday, January 24, 2024 6:25 PM
> To: Michael Brown ; devel@edk2.groups.io
> Cc: Gerd Hoffmann ; Laszlo Ersek
> Subject: RE: [PATCH v3 4/5] MdeModulePkg: Add self-tests for
> NestedInterr
On Wed, Jan 24, 2024 at 5:20 AM Doug Flick via groups.io
wrote:
>
> From: Doug Flick
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4537
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4538
>
> SECURITY PATCH - Patch
>
> TCBZ4537
> CVE-2023-45232
> CVSS 7.5 : CVSS:3.1/AV:N/AC:L/PR:N/
On Tue, Jan 23, 2024 at 07:33:24PM -0800, Doug Flick via groups.io wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4535
>
> SECURITY PATCH - Patch
Not needed, the CVE number below implies that.
> TCBZ4535
Not needed, the link to tianocore bugzilla is above.
> CVE-2023-45230
> CVSS
On Tue, Jan 23, 2024 at 07:33:25PM -0800, Doug Flick via groups.io wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4535
>
> SECURITY PATCH - Unit Tests
>
> TCBZ4535
> CVE-2023-45230
> CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
> CWE-119 Improper Restriction of Operations
On Tue, Jan 23, 2024 at 07:33:26PM -0800, Doug Flick via groups.io wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4534
>
> SECURITY PATCH - Patch
>
> TCBZ4534
> CVE-2023-45229
> CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
> CWE-125 Out-of-bounds Read
>
> Cc: Saloni Kasb
On Tue, Jan 23, 2024 at 07:33:28PM -0800, Doug Flick via groups.io wrote:
> From: Doug Flick
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4536
>
> SECURITY PATCH - Patch
>
> TCBZ4536
> CVE-2023-45231
> CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
> CWE-125 Out-of-bounds Rea
Hi,
> Why isn't this just a
>
> struct Ipv6Option {
> UINT8 OptionType;
> UINT8 OptionLength;
> UINT8 OptionData[];
> };
That makes sense indeed (for dhcpv6 we have that,
see EFI_DHCP6_PACKET_OPTION).
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages
On Tue, Jan 23, 2024 at 07:33:32PM -0800, Doug Flick via groups.io wrote:
> From: Doug Flick
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4539
>
> SECURITY PATCH - Patch
>
> TCBZ4539
> CVE-2023-45234
> CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
> CWE-119 Improper Restrict
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Liu, Zhiguang
> Sent: Tuesday, January 23, 2024 3:16 PM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Ni, Ray ; Laszlo
> Ersek ; Kumar, Rahul R ; Gerd
> Hoffmann ; Lee, Crystal ;
> Pedro Falcato
> Subject: [PATCH v3] UefiCp
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Huang, Jenny
> Sent: Tuesday, January 23, 2024 11:26 AM
> To: Sheng, W ; devel@edk2.groups.io
> Cc: Ni, Ray ; Chiang, Chris
> Subject: RE: [PATCH] MdeModulePkg/PciBusDxe: Add feedback status for
> PciIoMap
>
> Reviewed by Jen
On Fri, Jan 12, 2024 at 08:56:02AM +, Ni, Ray wrote:
> It's strange to me that ARM's MM env still allows modifying HOBs.
Yes.
But fixing that is beyond the scope of this patch, which just
fixes the integer overflow in CreateHob().
Can we please move forward and get the remaining CreateHob()
On Tue, Jan 23, 2024 at 03:16:32PM +, Guo, Gua wrote:
> For MdeModulePkg, I think no need to change because no any logic change.
>
> For StandaloneMmPkg and EmbeddedPkg
> - Don't have enough abilities to close Sami Mujawar and Ni Ray open
> currently, so hold on the change until I find how to
On 1/23/24 17:11, Gerd Hoffmann wrote:
> Hi,
>
> Well, it's OVMF in a virtual machine. No boot guard involved.
> So we could probably go for a OVMF-specific patch here.
>
> But I'd prefer to figure what exactly is happening here before going
> down that route. An extreme sl
On 1/23/24 17:59, Michael Brown wrote:
> On 23/01/2024 16:32, Laszlo Ersek wrote:
>> On 1/23/24 16:31, Michael Brown wrote:
>>> At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
>>> specification) and so we should never encounter a situation in which
>>> an interrupt occurs at TPL_HIG
W dniu 19.01.2024 o 20:18, Leif Lindholm pisze:
On Tue, Jan 16, 2024 at 08:48:32 +0100, Marcin Juszkiewicz wrote:
This library provides functions to check for hardware information.
For now it covers CPU ones:
- amount of cpu cores
- MPIDR value for cpu core
- NUMA node id for cpu core
Values a
W dniu 19.01.2024 o 20:20, Leif Lindholm pisze:
On Tue, Jan 16, 2024 at 08:48:34 +0100, Marcin Juszkiewicz wrote:
During platform initialization we read amount of cpu cores and set
PcdCoreCount so there is no need to call FdtHandler.
Signed-off-by: Marcin Juszkiewicz
---
Platform/Qemu/SbsaQe
On 1/23/24 18:41, Michael Brown wrote:
> On 23/01/2024 16:55, Laszlo Ersek wrote:
>>> + ///
>>> + /// Number of self-tests performed.
>>> + ///
>>> + UINTN SelfTestCount;
>>> } NESTED_INTERRUPT_STATE;
>>> /**
>>
>> I suggest that the new field be UINT32. The (exclusive) limit is a
>>
On 1/23/24 23:52, Michael D Kinney wrote:
> * Add InitializeFloatingPointUnits() to x86 specific file
> * Add GetCpuFamilyModel() to x86 specific file
> * Add GetCpuSteppingId() to x86 specific file
> * Move StandardSignatureIsAuthenticAMD() to x86 specific file.
> * Add CpuLib library class includ
On 1/24/24 09:11, Ni, Ray wrote:
> Felix, I remember you mentioned to me about the usage of SMI handler
> unregistering itself.
I wanted to ask: is this something that the PI spec comments on? I.e.,
is this usage expected by the spec (in which case this bugfix is a
conformance fix), or is the spe
Hi,
> So, yesterday I read your status on virt-staff, and I found an entry in
> it that resembled this upstream thread pretty closely. However, your
> status was the *only* mention of "mdev" specifically, and so I wasn't
> sure if *mdev* meant the same thing as the more generic upstream
> expres
meta (CC Mike):
On 1/22/24 19:25, ryderkeys via groups.io wrote:
> (Originally sent to edk2 discuss but it looks like my message has
> been stuck in moderation for a week, so I thought I would try here
> instead.)
I'm now checking the moderation queue for edk2-discuss; I seem to have
found your o
This library provides functions to check for hardware information.
For now it covers CPU ones:
- amount of cpu cores
- MPIDR value for cpu core
- NUMA node id for cpu core
Values are read from TF-A using platform specific SMC calls.
Signed-off-by: Marcin Juszkiewicz
---
Platform/Qemu/SbsaQemu/
We read it once and store in Pcd for future use.
Signed-off-by: Marcin Juszkiewicz
---
.../SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf | 4 +++-
.../SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c | 9 +
2 files changed, 8 insertions(+), 5 deletions(-)
diff
During platform initialization we read amount of cpu cores and set
PcdCoreCount so there is no need to call FdtHandler.
Signed-off-by: Marcin Juszkiewicz
---
Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf | 6 ++
Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c|
There is no need for EDK2 to know that there is DeviceTree around.
All hardware information is read using functions from
SbsaQemuHardwareInfoLib library.
Library fallbacks to parsing DT if needed (used with too old TF-A).
Signed-off-by: Marcin Juszkiewicz
Reviewed-by: Leif Lindholm
---
Platfor
In case we do not have cpu information (SMC call fails,
our minimal DT lacks info) we hang.
TODO: shutdown instead
Signed-off-by: Marcin Juszkiewicz
---
.../SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
a/Silicon/Qemu/Sb
We want to stop parsing DeviceTree to gather hardware information.
Instead we ask TF-A for those details using SMC calls. On real hardware
platform it could be asking on-board Embedded Controller.
If TF-A answer to SMC call would be not success then we assume that it
is old version and go back to
On 1/23/24 21:24, Michael D Kinney wrote:
> Provide an optional method for PEI to declare a specific address
> range to use for the Memory Type Information bins. The current
> algorithm uses heuristics that tends to place the Memory Type
> Information bins in the same location, but memory configura
On 1/23/24 21:24, Michael D Kinney wrote:
> Provide an optional method for PEI to declare a specific address
> range to use for the Memory Type Information bins. The current
> algorithm uses heuristics that tends to place the Memory Type
> Information bins in the same location, but memory configura
"The CpuDxe interface will be the wrapper." Yes, of course. It needs to be
added. I was just saying that maybe any CMO checking is not required there
as cmo library will take care of it.
On Tue, Jan 23, 2024 at 10:24 PM Sunil V L wrote:
> On Tue, Jan 23, 2024 at 11:42:57AM +0530, Dhaval Sharma w
On Wed, Jan 24, 2024 at 07:57:27PM +0530, Dhaval Sharma wrote:
> "The CpuDxe interface will be the wrapper." Yes, of course. It needs to be
> added. I was just saying that maybe any CMO checking is not required there
> as cmo library will take care of it.
>
That's correct.
> On Tue, Jan 23, 2024
On 1/23/24 19:49, Doug Flick via groups.io wrote:
> Gerd,
>
> As a new EDK2 developer, I'm working through getting the patches up
> to EDK2 but I have to follow the EDK2 patch process which is not the
> fastest thing to follow and also not my day job. If you want to see
> where I am you can look a
On 1/24/24 14:26, Gerd Hoffmann wrote:
> Hi,
>
>> So, yesterday I read your status on virt-staff, and I found an entry in
>> it that resembled this upstream thread pretty closely. However, your
>> status was the *only* mention of "mdev" specifically, and so I wasn't
>> sure if *mdev* meant the s
Mike:
Seemly, I miss this patch.
Dhaval:
I add one comment below.
> -邮件原件-
> 发件人: devel@edk2.groups.io 代表 Michael D
> Kinney
> 发送时间: 2024年1月24日 10:24
> 收件人: devel@edk2.groups.io; dha...@rivosinc.com
> 抄送: Gao, Liming ; Liu, Zhiguang
> ; Bi, Dandan ; Pedro Falcato
> ; Chiu, Chasel ;
On 1/24/24 15:35, Laszlo Ersek wrote:
> I figure the most flexible approach for those that dislike email-based
> review for embargoed patches would be if github.com supported locked
> down *PRs* (i.e., not private organizatons). In other words, if those
> PRs would be submitted against the same ba
Mike:
Current algorithm tries to reserve the top available memory for memory type
bin range.
If the platform uses new way to describe the memory range, should we
suggest the rule to still
use the top memory resource hob for the memory type bin range?
Thanks
Liming
> -邮件原件-
> 发件人: Mich
Specifically before running lzma uncompress of the main firmware volume.
This is needed to make sure caching is enabled, otherwise the uncompress
can be extremely slow.
Adapt the ASSERTs in PlatformInitLib to the changes.
Background: In some virtual machine configurations with assigned
devices k
I agree on your sentiment about Bugzilla (bz) not being ideal for this.
This space has been a multi-year journey from usrt-based tickets, bespoke
advisories, bz, etc into today's world of tianocore infosec, tianocore as
its own CVE Naming Authority (CNA) and working to leverage the extant
features
On 1/24/24 16:20, Vincent Zimmer wrote:
> I agree on your sentiment about Bugzilla (bz) not being ideal for this.
> This space has been a multi-year journey from usrt-based tickets,
> bespoke advisories, bz, etc into today's world of tianocore infosec,
> tianocore as its own CVE Naming Authority (C
Neat when doing ResetVector coding.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/ResetVector/DebugCon.asm | 43 +++
OvmfPkg/ResetVector/ResetVector.nasmb | 2 +-
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 OvmfPkg/ResetVector/DebugCon.asm
diff
Hi All,
Please see my response inline marked [SAMI].
Regards,
Sami Mujawar
On 24/01/2024, 12:41, "Gerd Hoffmann" mailto:kra...@redhat.com>> wrote:
On Fri, Jan 12, 2024 at 08:56:02AM +, Ni, Ray wrote:
> It's strange to me that ARM's MM env still allows modifying HOBs.
[SAMI] We are invest
The ResetVector decides at runtime (depending in CPU capabilities)
whenever it uses 5-level paging or not. Firmware builds with 5-level
paging enabled (PcdUse5LevelPageTable=TRUE) may run run in 4-level
paging mode. The code handles that just fine, by looking at the la57
bit in cr4 instead of che
On 1/24/24 16:15, Gerd Hoffmann wrote:
> Specifically before running lzma uncompress of the main firmware volume.
> This is needed to make sure caching is enabled, otherwise the uncompress
> can be extremely slow.
>
> Adapt the ASSERTs in PlatformInitLib to the changes.
>
> Background: In some v
On 1/24/24 15:59, gaoliming via groups.io wrote:
> Mike:
> Current algorithm tries to reserve the top available memory for memory type
> bin range.
> If the platform uses new way to describe the memory range, should we
> suggest the rule to still
> use the top memory resource hob for the memor
spec does not say the unregistration is allowed inside handler. it's just to
improve the qualiquali the code.
thanks,
ray
From: Laszlo Ersek
Sent: Wednesday, January 24, 2024 9:06:13 PM
To: devel@edk2.groups.io ; Ni, Ray ;
Liu, Zhiguang
Cc: Liming Gao ; Wu, Jia
On 1/24/24 16:49, Gerd Hoffmann wrote:
> The ResetVector decides at runtime (depending in CPU capabilities)
(1) s/depending in/dependent on/
> whenever it uses 5-level paging or not. Firmware builds with 5-level
> paging enabled (PcdUse5LevelPageTable=TRUE) may run run in 4-level
(2) typo: "run
- Create include files to reduce duplication.
- Fix varpolicy command.
- Little CI tweak.
Gerd Hoffmann (11):
OvmfPkg: add ShellComponents.dsc.inc
OvmfPkg: add ShellLibs.dsc.inc
OvmfPkg: add ShellDxe.fdf.inc
OvmfPkg: Shell*.inc: allow building without network support
OvmfPkg: ShellDxe.fd
Move EFI Shell firmware volume files to
the new ShellDxe.fdf.inc file.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/OvmfPkgX64.fdf | 11 ++-
OvmfPkg/Include/Fdf/ShellDxe.fdf.inc | 14 ++
2 files changed, 16 insertions(+), 9 deletions(-)
create mode 100644 OvmfPkg/I
Move EFI Shell libraries from OvmfPkgX64.dsc to
the new ShellComponents.dsc.inc include file.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Include/Dsc/ShellLibs.dsc.inc | 11 +++
OvmfPkg/OvmfPkgX64.dsc| 11 +--
2 files changed, 16 insertions(+), 6 deletions(-)
create
Add NETWORK_ENABLE conditionals for the components
which need network support.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Include/Dsc/ShellComponents.dsc.inc | 4
OvmfPkg/Include/Fdf/ShellDxe.fdf.inc| 2 ++
2 files changed, 6 insertions(+)
diff --git a/OvmfPkg/Include/Dsc/ShellCompon
Move EFI Shell components from OvmfPkgX64.dsc to
the new ShellComponents.dsc.inc include file.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Include/Dsc/ShellComponents.dsc.inc | 49 +
OvmfPkg/OvmfPkgX64.dsc | 43 +-
2 files changed, 50 inserti
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/OvmfPkgIa32X64.dsc | 54 +-
OvmfPkg/OvmfPkgIa32X64.fdf | 11 ++--
2 files changed, 8 insertions(+), 57 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 5e9eee628aea..4d57026bb1
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/IntelTdx/IntelTdxX64.dsc | 33 +++-
OvmfPkg/IntelTdx/IntelTdxX64.fdf | 9 ++---
2 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 82e3e
Place the EFI shell as EFI/BOOT/BOOT{ARCH}.EFI on the virtual drive.
This allows the "run to shell" CI test case to work even in case the
shell is not included in the firmware image.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/PlatformCI/PlatformBuildLib.py | 12 +++-
1 file changed, 11 ins
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/AmdSev/AmdSevX64.dsc | 32 ++--
OvmfPkg/AmdSev/AmdSevX64.fdf | 8 ++--
2 files changed, 4 insertions(+), 36 deletions(-)
diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index a31a89344a60..41c61467
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Microvm/MicrovmX64.dsc | 55 --
OvmfPkg/Microvm/MicrovmX64.fdf | 9 ++
2 files changed, 14 insertions(+), 50 deletions(-)
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 063324cd0572.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/OvmfPkgIa32.dsc | 49 ++---
OvmfPkg/OvmfPkgIa32.fdf | 11 ++---
2 files changed, 4 insertions(+), 56 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 28379961a78e..23f949fd9845 10064
Needed to make the new 'varpolicy' EFI shell command
actually available in the OVMF firmware builds.
Fixes: fe6cd1c18721 ("OvmfPkg: Add varpolicy shell command")
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Include/Fdf/ShellDxe.fdf.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/OvmfPkg/Incl
On 1/24/24 16:31, Gerd Hoffmann wrote:
> Neat when doing ResetVector coding.
>
> Signed-off-by: Gerd Hoffmann
> ---
> OvmfPkg/ResetVector/DebugCon.asm | 43 +++
> OvmfPkg/ResetVector/ResetVector.nasmb | 2 +-
> 2 files changed, 44 insertions(+), 1 deletion(-)
> cre
On Wed, Jan 24, 2024 at 07:20:34AM -0800, Vincent Zimmer wrote:
> I agree on your sentiment about Bugzilla (bz) not being ideal for this.
> This space has been a multi-year journey from usrt-based tickets, bespoke
> advisories, bz, etc into today's world of tianocore infosec, tianocore as
> its own
Hi,
> > static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> > {
> > [ ... ]
> > * When there is no need to deal with noncoherent DMA (e.g., no VT-d
> > * or VT-d has snoop control), guest CD/MTRR/PAT are all ignored.
> > The
> > * EPT memory t
Hi Pierre,
Thank you for this patch.
These changes look good to me.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:
Rename PERFORMANCE_PROTOCOL_VERSION to reflect the different
versions of the protocol. The macro
Hi Pierre,
Thank you for this patch.
These changes look good to me.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:
The PERFORMANCE_DESCRIBE_FASTCHANNEL Scmi command is available
since SCMI v2.0 and allows to que
Hi Pierre,
Thank you for this patch.
These changes look good to me.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:
Make use of the newly added CPC revision macro.
Signed-off-by: Pierre Gondois mailto:pierre.go
Hi Pierre,
Thank you for this patch.
These changes look good to me.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:
The DynamicTables framework uses the AmlLib to generate some
Aml objects. It is done by using st
Hi Pierre,
Thank you for this patch.
Please see my response inline marked [SAMI].
Regards,
Sami Mujawar
On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:
Add an object describing _PSD information, cf. ACPI 6.5,
s8.4.5.5 _PSD (P-State Dependency).
Also add the corr
Hi Pierre,
Thank you for this patch.
I have a minor suggestion that I will fix before merging.
Otherwise, this patch looks good to me.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
On 12/12/2023, 09:30, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:
The _PSD object (cf. ACPI 6.5
In my opinion this is not a spec conformance fix, but it is a bug fix.
The spec does not explicitly mentions unregistering from within the handler,
but by applying a principle that everything that's not forbidden is legal,
it's fair for a caller to expect that unregistering works fine in any valid
Hi Pierre,
Thank you for this patch.
These changes look good to me.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
On 12/12/2023, 09:30, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:
Make use of the newly added AmlCreatePsdNode() to generate
_PSD objects.
_PSD objects allow to
On 1/24/24 18:15, Felix Polyudov via groups.io wrote:
> In my opinion this is not a spec conformance fix, but it is a bug fix.
>
> The spec does not explicitly mentions unregistering from within the handler,
>
> but by applying a principle that everything that’s not forbidden is legal,
>
> it
Hi Pierre,
Please see my feedback inline marked [SAMI].
Regards,
Sami Mujawar
On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:
Add AmlCreatePsdNode() to the AmlLib to generate _PSD objects.
_PSD objects allow to describe 'performance control, P-state
or CPPC, log
Hi Pierre,
I think we should not relax the checks as this may lead to a production
platform ignoring the mandatory fields.
Maybe we need to define a pre-processor e.g. DEVELOPMENT_PLATFORM_RELAXATIONS
and add additional warnings to say that the platform is not spec compliant.
Regards,
Sami Muj
Hi Laszlo,
Responses below.
Mike
> -Original Message-
> From: Laszlo Ersek
> Sent: Wednesday, January 24, 2024 6:17 AM
> To: devel@edk2.groups.io; Kinney, Michael D
> Cc: Liming Gao ; Li, Aaron
> ; Liu, Yun Y ; Andrew Fish
>
> Subject: Re: [edk2-devel] [Patch v2 1/1] MdeModulePkg/Core
Hi Laszlo,
Yes. I can add more details in the commit message.
The impact is for ACPI S4. There are many reasons why the set of
HOBs passed into the DXE Core may change from boot to boot or that
allocations in the early DXE init phase should change where the
memory type information bins are allo
Hi Liming,
The current algorithm allocates the bins from the top of the first
memory range given to the DXE Core. This is not guaranteed to be
the top of RAM. The heuristic will use the memory range from the
PHIT HOB if it is considered big enough. If PHIT is not big enough
then a search of the
On 1/22/2024 6:14 PM, Rebecca Cran wrote:
Thanks! I wonder if the same problem occurs on LoongArch64, which also
defines the runtime page allocation granularity to be 0x1?
Yes, it should have exactly the same problem
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent
Reviewed-by: Michael D Kinney
> -Original Message-
> From: Douglas Flick [MSFT]
> Sent: Tuesday, January 23, 2024 7:34 PM
> To: devel@edk2.groups.io
> Cc: Douglas Flick [MSFT] ; Kinney, Michael D
> ; Liming Gao ;
> Liu, Zhiguang
> Subject: [PATCH 11/14] MdePkg: Test: Add gRT_GetTime Goo
On 1/24/24 10:47, Laszlo Ersek wrote:
On 1/24/24 16:31, Gerd Hoffmann wrote:
Neat when doing ResetVector coding.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/ResetVector/DebugCon.asm | 43 +++
OvmfPkg/ResetVector/ResetVector.nasmb | 2 +-
2 files changed, 44 inser
On 1/23/2024 7:10 AM, Sami Mujawar wrote:
@@ -310,6 +318,7 @@ GenericWatchdogEntry (
{
EFI_STATUS Status;
EFI_HANDLE Handle;
+ UINT32 WatchdogIId;
[SAMI] Minor, the above variable name should be WatchdogIid to comply with the
coding standard.
I was wondering about the naming, since it's the "
On 1/24/24 13:24, Tom Lendacky wrote:
On 1/24/24 10:47, Laszlo Ersek wrote:
On 1/24/24 16:31, Gerd Hoffmann wrote:
Neat when doing ResetVector coding.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/ResetVector/DebugCon.asm | 43 +++
OvmfPkg/ResetVector/ResetVector.na
This adds an additional option to the dmem UEFI shell command for verbose
dumping of a couple of UEFI tables.
The tables specified are the RT Properties Table, the Image Execution Table,
and the Conformance Profiles table.
Supporting objects are added in the .inf and .uni files relating to Dmem
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4352
Implemented the dumping of the UEFI RT Properties Table using Dmem.c
Cc: Ray Ni
Cc: Zhichao Gao
Signed-off-by: Sam Kaynor
---
ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c |
62
ShellPk
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4352
Implemented dumping of the Image Execution Table using Dmem.c
Cc: Ray Ni
Cc: Zhichao Gao
Signed-off-by: Sam Kaynor
---
ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c |
139
ShellPkg/Libr
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4352
Implemented dumping of the UEFI Conformance Profiles Table using Dmem.c
Additionally added the base support for the table with new
header file ConformanceProfiles.h (Cc'd maintainers of MdePkg for this)
Cc: Ray Ni
Cc: Zhichao Gao
Cc: Mich
Reviewed-by: Liming Gao
> -邮件原件-
> 发件人: Laszlo Ersek
> 发送时间: 2024年1月24日 21:00
> 收件人: Michael D Kinney ;
> devel@edk2.groups.io
> 抄送: Liming Gao ; Zhiguang Liu
> ; Qing Huang
> 主题: Re: [Patch 1/1] MdePkg/Library/BaseCpuLibNull: Add missing X86
> specific services
>
> On 1/23/24 23:52, M
Mike:
I suggest to document the recommended usage of the specified memory type info
bin range. I worry that someone configures the low memory range for the memory
type info bin range. It may still cause S4 failure.
Thanks
Liming
> -邮件原件-
> 发件人: Kinney, Michael D
> 发送时间: 2024年1月25日 1:
Agree.
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Gerd Hoffmann
> Sent: Wednesday, January 24, 2024 8:41 PM
> To: Ni, Ray
> Cc: Guo, Gua ; devel@edk2.groups.io; Marc Beatove
> ; Ard Biesheuvel ;
> Sami Mujawar ; Mathews, John
>
> Subject: Re: RE: [PATCH v3 2/4] Standa
Hi Liming,
The exact range that may or may not support S4 resume may be OS dependent.
I am not sure.
In general, a UEFI OS should not be dependent on specific UEFI memory
types being above or below specific addresses.
The only S4 requirement I know of is landing the memory types at the
same addr
Same for TDX, I did not run it but it should cause failure
as debugShowPostCode is called OvmfPkg/ResetVector/Ia32/IntelTdx.asm before
actually the #VE handlers are installed.
-Erdem
On Wed, Jan 24, 2024 at 11:55 AM Tom Lendacky
wrote:
> On 1/24/24 13:24, Tom Lendacky wrote:
> > On 1/24/24 10:4
Always good to reduce duplication!
Thanks for doing that.
Acked-by: Jiewen Yao
> -Original Message-
> From: Gerd Hoffmann
> Sent: Thursday, January 25, 2024 12:38 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Ard Biesheuvel
> ; Michael Roth ; Gerd
> Hoffmann ; Laszlo Ersek ; Aktas,
From: Gua Guo
Crypto in serveral case will use old version, treat as optional
will make customer easy to upgrade it.
Cc: Guo Dong
Cc: Sean Rhodes
Cc: James Lu
Cc: Gua Guo
Signed-off-by: Gua Guo
---
UefiPayloadPkg/UefiPayloadPkg.dsc | 3 +++
UefiPayloadPkg/UefiPayloadPkg.fdf | 2 ++
2 files
Gentle reminder, please review the patch series.
On 18-01-2024 09:24, Abdul Lateef Attar via groups.io wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
From: Abdul Lateef Attar
Resending the patch wi
From: Gua Guo
Crypto in serveral case will use old version or latest version,
Platform may choose to only update Crypto drivers without updating
whole UPL, in this case the Crypto driver will provide by platform
payload outside the common UPL binary.
Cc: Chasel Chiu
Cc: Guo Dong
Cc: Sean Rhode
Reviewed-by: James Lu
Thanks,
James
-Original Message-
From: Guo, Gua
Sent: Thursday, January 25, 2024 1:09 PM
To: devel@edk2.groups.io
Cc: Guo, Gua ; Chiu, Chasel ; Dong,
Guo ; Rhodes, Sean ; Lu, James
Subject: [PATCH v2] UefiPayloadPkg/Crypto: Support external Crypto drivers.
On Wed, Jan 24, 2024 at 05:14:10PM +0100, Laszlo Ersek wrote:
> On 1/24/24 16:15, Gerd Hoffmann wrote:
> > Specifically before running lzma uncompress of the main firmware volume.
> > This is needed to make sure caching is enabled, otherwise the uncompress
> > can be extremely slow.
> >
> > Adapt
On Wed, Jan 24, 2024 at 05:43:29PM -0800, Erdem Aktas wrote:
> Same for TDX, I did not run it but it should cause failure
> as debugShowPostCode is called OvmfPkg/ResetVector/Ia32/IntelTdx.asm before
> actually the #VE handlers are installed.
>
> > Had a meeting get canceled and so got a chance to
1 - 100 of 101 matches
Mail list logo
