|
Re: [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64
The code changes by itself look fine to me. The only problem I see is
that we cannot run arbitrary code on other cores with the MMU off,
given that in that case, they don't comply with the UEFI
The code changes by itself look fine to me. The only problem I see is
that we cannot run arbitrary code on other cores with the MMU off,
given that in that case, they don't comply with the UEFI
|
By
Ard Biesheuvel <ardb@...>
·
#702
·
|
|
Re: [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64
Ard/Sami - any comments?
/
Leif
Ard/Sami - any comments?
/
Leif
|
By
Leif Lindholm <leif@...>
·
#701
·
|
|
Re: [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64
Just to add to this:
Aff0 was never defined by the architecture to be the "core", it was
just the smallest schedulable entity. The intent being that whether
you had multiple hardware threads per core
Just to add to this:
Aff0 was never defined by the architecture to be the "core", it was
just the smallest schedulable entity. The intent being that whether
you had multiple hardware threads per core
|
By
Leif Lindholm <leif@...>
·
#700
·
|
|
[RFC] [PATCH 2/2] ArmPkg: Add Library/MpInitLib to support EFI_MP_SERVICES_PROTOCOL
Add support for EFI_MP_SERVICES_PROTOCOL during the DXE phase under
AArch64.
Call PSCI_CPU_ON to power on the core, call the supplied procedure and
then call PSCI_CPU_OFF to power off the
Add support for EFI_MP_SERVICES_PROTOCOL during the DXE phase under
AArch64.
Call PSCI_CPU_ON to power on the core, call the supplied procedure and
then call PSCI_CPU_OFF to power off the
|
By
Rebecca Cran <rebecca@...>
·
#699
·
|
|
[RFC] [PATCH 1/2] ArmPkg: Replace CoreId and ClusterId with Mpidr in ARM_CORE_INFO struct
Remove the ClusterId and CoreId fields in the ARM_CORE_INFO structure in
favor of a new Mpidr field. Update code in
ArmPlatformPkg/PrePeiCore/MainMPCore and ArmPlatformPkg/PrePi/MainMPCore.c
to use
Remove the ClusterId and CoreId fields in the ARM_CORE_INFO structure in
favor of a new Mpidr field. Update code in
ArmPlatformPkg/PrePeiCore/MainMPCore and ArmPlatformPkg/PrePi/MainMPCore.c
to use
|
By
Rebecca Cran <rebecca@...>
·
#698
·
|
|
[RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64
I'd like to propose adding EFI_MP_SERVICES_PROTOCOL support for
AARCH64 systems. I've attached two patches to implement support for it
in the DXE phase, based on code in EmulatorPkg and UefiCpuPkg.
I'd like to propose adding EFI_MP_SERVICES_PROTOCOL support for
AARCH64 systems. I've attached two patches to implement support for it
in the DXE phase, based on code in EmulatorPkg and UefiCpuPkg.
|
By
Rebecca Cran <rebecca@...>
·
#697
·
|
|
RFC: Static Analysis in edk2 CI
I would like to start a discussion regarding integration of the static analysis (SA) into the edk2 workflow.
I assume the SA benefits are well understood, so I'll get straight to the point; however,
I would like to start a discussion regarding integration of the static analysis (SA) into the edk2 workflow.
I assume the SA benefits are well understood, so I'll get straight to the point; however,
|
By
Felix Polyudov
·
#696
·
|
|
Re: [edk2-devel] RFC: Common Design Proposal on Confidential Computing Support in OVMF
Hello Jiewen,
Thanks for writing this up. As you know, ARM is a bit behind in the
CCA space, and so I will not be able to take part in these discussions
in great detail.
I will leave it to the
Hello Jiewen,
Thanks for writing this up. As you know, ARM is a bit behind in the
CCA space, and so I will not be able to take part in these discussions
in great detail.
I will leave it to the
|
By
Ard Biesheuvel <ardb@...>
·
#695
·
|
|
[edk2-devel] RFC: Common Design Proposal on Confidential Computing Support in OVMF
Hi
I would like to raise the topic on a confidential computing support in OVMF.
The main target is AMD SEV feature and Intel TDX feature in OVMF package.
The goal is to create a guidance for our
Hi
I would like to raise the topic on a confidential computing support in OVMF.
The main target is AMD SEV feature and Intel TDX feature in OVMF package.
The goal is to create a guidance for our
|
By
Yao, Jiewen
·
#694
·
|
|
Re: [edk2-devel] RFC: EXT4 filesystem driver
The EFI System Partition is defined to be FAT32 by the UEFI Spec for interoperability. It defines the file system drivers required for the firmware and OS. So changing that is not really an option.
The EFI System Partition is defined to be FAT32 by the UEFI Spec for interoperability. It defines the file system drivers required for the firmware and OS. So changing that is not really an option.
|
By
Andrew Fish <afish@...>
·
#693
·
|
|
Re: [edk2-devel] RFC: EXT4 filesystem driver
Hi Pedro,
By
Nate DeSimone
·
#692
·
|
|
Re: RFC: EXT4 filesystem driver
By
Michael D Kinney
·
#691
·
|
|
Re: [edk2-devel] RFC: EXT4 filesystem driver
Hi Andrew, Marvin,
RE: The package name: It doesn't sound like a bad idea to have
something like a FileSystemPkg and have a bunch of different
filesystems inside of it, but I'll defer to you
and my
Hi Andrew, Marvin,
RE: The package name: It doesn't sound like a bad idea to have
something like a FileSystemPkg and have a bunch of different
filesystems inside of it, but I'll defer to you
and my
|
By
Pedro Falcato
·
#690
·
|
|
Re: [edk2-devel] [edk2-rfc] RFC: EXT4 filesystem driver
I think the Terminal driver may have some similar logic to convert UTF-8 terminals to/from the UEFI
I think the Terminal driver may have some similar logic to convert UTF-8 terminals to/from the UEFI
|
By
Andrew Fish <afish@...>
·
#689
·
|
|
回复: [edk2-rfc] RFC: EXT4 filesystem driver
Current MdePkg BaseLib has CalculateCrc32(). So, CRC32C and CRC16 can be added into BaseLib.
If more modules need to consume Ucs2 <-> Utf8 conversion library, BaseUcs2Utf8Lib is generic enough
to be
Current MdePkg BaseLib has CalculateCrc32(). So, CRC32C and CRC16 can be added into BaseLib.
If more modules need to consume Ucs2 <-> Utf8 conversion library, BaseUcs2Utf8Lib is generic enough
to be
|
By
gaoliming
·
#688
·
|
|
RFC: EXT4 filesystem driver
EXT4 (fourth extended filesystem) is a filesystem developed for Linux
that has been in wide use (desktops, servers, smartphones) since 2008.
The Ext4Pkg implements the Simple File System Protocol for
EXT4 (fourth extended filesystem) is a filesystem developed for Linux
that has been in wide use (desktops, servers, smartphones) since 2008.
The Ext4Pkg implements the Simple File System Protocol for
|
By
Pedro Falcato
·
#687
·
|
|
回复: 回复: 回复: [edk2-rfc] release candidate tags
There is no other comment for this proposal. I will send it to edk2 devel mail list to collect the feedback.
Thanks
Liming
There is no other comment for this proposal. I will send it to edk2 devel mail list to collect the feedback.
Thanks
Liming
|
By
gaoliming
·
#686
·
|
|
Re: [edk2-devel] RFC: design review for TDVF in OVMF
Thanks much everyone who attended 2 sessions of TDVF design review meeting
and lots of valuable comments and feedbacks received. These 2 meetings were
recorded and now uploaded to below link:
Session
Thanks much everyone who attended 2 sessions of TDVF design review meeting
and lots of valuable comments and feedbacks received. These 2 meetings were
recorded and now uploaded to below link:
Session
|
By
Min Xu <min.m.xu@...>
·
#685
·
|
|
Re: 回复: 回复: [edk2-rfc] release candidate tags
Thank you. A shorter SFF should not be a problem, as we use it anyway
only for merging previously reviewed feature patch sets.
I hope other community members are OK with this as
Thank you. A shorter SFF should not be a problem, as we use it anyway
only for merging previously reviewed feature patch sets.
I hope other community members are OK with this as
|
By
Laszlo Ersek
·
#684
·
|
|
回复: 回复: [edk2-rfc] release candidate tags
Laszlo:
OK. I give the new proposed date for the release planning. SFF will be shorten to 5 days. HFF will be extended to 14 days.
Date (00:00:00 UTC-8) Description
2021-05-28 Beginning of
Laszlo:
OK. I give the new proposed date for the release planning. SFF will be shorten to 5 days. HFF will be extended to 14 days.
Date (00:00:00 UTC-8) Description
2021-05-28 Beginning of
|
By
gaoliming
·
#683
·
|