This patch is to remove legacy SmBase relocation in
PiSmmCpuDxeSmm Driver. The responsibility for SmBase
relocation has been transferred to the SmmRelocationInit
interface, which now handles the following tasks:
1. Relocates the SmBase for each processor.
2. Generates the gSmmBaseHobGuid HOB.
As a
This patch is to consume SmmRelocationInit for SmBase
Relocation.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Cc: Ray Ni
Signed-off-by: Jiaxin Wu
---
OvmfPkg/PlatformPei/Platform.c | 3 +
OvmfPkg/PlatformPei/Platform.h | 5 ++
OvmfPkg/Platfor
This patch just includes SmmRelocationLib in UefiPayloadPkg.
Cc: Guo Dong
Cc: Sean Rhodes
Cc: James Lu
Cc: Gua Guo
Cc: Ray Ni
Signed-off-by: Jiaxin Wu
Reviewed-by: Gua Guo
Reviewed-by: Guo Dong
---
UefiPayloadPkg/UefiPayloadPkg.dsc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Uef
Based on gSmmBaseHobGuid:
If gSmmBaseHobGuid found, means SmBase info has been relocated
and recorded in the SmBase array.
So, this patch check smbase relocation is done or not in
SmmCpuFeaturesInitializeProcessor().
With SmmRelocationLib, gSmmBaseHobGuid will be always created.
Here this patch ju
This patch refines the SmmAccess implementation:
1. SmramMap will be retrieved from the
gEfiSmmSmramMemoryGuid instead of original from
the TSEG Memory Base register.
2. Remove the gEfiAcpiVariableGuid creation, thus
the DESCRIPTOR_INDEX definition can be also cleaned.
3. The gEfiAcpiVariableGuid H
Background:
In the PiSmmCpuDxeSmm driver, SMRAM allocation for SMI
handlers and processor Save State areas was traditionally
performed using the Smst->AllocatePages() function during
the DXE phase. The introduction of SmmRelocationLib
changes this process by moving the allocation to the PEI
phase,
There are below 2 differences between AMD & OVMF according
existing implementation:
1.The mode of the CPU check is different between the AMD & OVMF.
OVMF:
CpuSaveState->x86.SMMRevId & 0X
AMD:
LMAValue = (UINT32)AsmReadMsr64 (EFER_ADDRESS) & LMA
2.Existing SmBase configuration is different be
Due to the definition difference of SMRAM Save State,
SmmBase config in SMRAM Save State for AMD is also different.
This patch provides the AmdSmmRelocationLib library instance
to handle the SMRAM Save State difference.
Cc: Abdul Lateef Attar
Cc: Abner Chang
Cc: Ray Ni
Cc: Zeng Star
Cc: Gerd
This patch aims on mProcessorInfo global variable, which can be
defined as local variable in SmmRelocateBases(). With this patch,
no need to allocate the memory for all CPUs to store the
Processor Info.
Cc: Ray Ni
Cc: Zeng Star
Cc: Gerd Hoffmann
Cc: Rahul Kumar
Signed-off-by: Jiaxin Wu
---
.
Since SMM relocation is performed serially for each CPU, there is
no need to allocate buffers for all CPUs to store the SmBase
address in mSmBase and the Rebased flag in mRebased. A defined
global variable is sufficient.
This patch focuses on the mSmBase and mRebased global variables
to prevent un
This patch aims to rename global variables for clearer
association with Smm Init, ensuring their names are
distinct from those used in the PiSmmCpuDxeSmm Driver.
Cc: Ray Ni
Cc: Zeng Star
Cc: Gerd Hoffmann
Cc: Rahul Kumar
Signed-off-by: Jiaxin Wu
---
.../Library/SmmRelocationLib/Ia32/SmmInit.
This patch just separates the smbase relocation logic from
PiSmmCpuDxeSmm driver, and moves to the SmmRelocationInit
interface. It maintains the original implementation of most
functions and leaves the definitions of global variables
intact. Further refinements to the code are planned for
subsequen
Intel plans to separate the smbase relocation logic from
PiSmmCpuDxeSmm driver, and the related behavior will be
moved to the new interface defined by the SmmRelocationLib
class.
The SmmRelocationLib class provides the SmmRelocationInit()
interface for platform to do the smbase relocation, which
s
PR: https://github.com/tianocore/edk2/pull/5546
Intel plans to separate the smbase relocation logic from
PiSmmCpuDxeSmm driver, and the related behavior will be
moved to the new interface defined by the SmmRelocationLib
class.
The SmmRelocationLib class provides the SmmRelocationInit()
interface
Thanks Mike. I shall make necessary changes and submit the PR again for review.
Regards,
JP
-Original Message-
From: Kinney, Michael D
Sent: Thursday, April 18, 2024 10:46 AM
To: Jayaprakash, N ; devel@edk2.groups.io
Cc: Rebecca Cran ; Kinney, Michael D
Subject: RE: [edk2-devel] [edk2
Please use MP Services Protocol APIs StartupAllAPs() or StarupThisAP()
to read/write MSRs on other logical processors.
There and many examples of this in the UefiCpuPkg to programming MSRs
on all the logical processors.
Mike
> -Original Message-
> From: Jayaprakash, N
> Sent: Wednesday
In the validation and debug scenarios, engineers tend to read MSRs and write to
MSRs of different CPUs.
So we are providing a simple mechanism through these APIs to enable them to do
these operations.
These APIs will be part of the edk2 module of the Python interpreter and will
be used during t
[AMD Official Use Only - General]
Thanks Thomas and Abner.
Reviewed-by:
For up-stream, please let us verify it first:
@Zhai, MingXin (Duke), Duke, please help verify this change on Chachani Board
and feedback.
Thanks,
Eric
> -Original Message-
> From: Chang, Abner
> Sent: Thursday, A
Hi,Sunil V L
How about this status.
Best Regards,
Yang Wang
> -原始邮件-
> 发件人: "Yang Wang"
> 发送时间: 2024-04-10 13:50:12 (星期三)
> 收件人: suni...@ventanamicro.com, g...@danielschaefer.me, devel@edk2.groups.io
> 抄送: "Yang Wang" , "Ran Wang" ,
> "YunFeng Yang" , "YaXing Guo" ,
> "Leif Lindhol
[AMD Official Use Only - General]
Reviewed-by:
Thanks
> -Original Message-
> From: Lendacky, Thomas
> Sent: Monday, April 15, 2024 11:01 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Gerd Hoffmann
> ; Roth, Michael ; Min Xu
> ; Leif Lindholm ; Michael D
> Kinney ; Chang, Abner
>
Hi Sachin
I like this clean up. Thanks for doing this.
I saw this patch is 6/6, but I did not see any other such as 1/6 ~ 5/6 in my
mailbox. Not sure what is happening on my side.
Just double confirm, have you sent those patches?
Thank you
Yao, Jiewen
> -Original Message-
> From: Sachi
Hi Yanbo,
I didn't do it in the way you suggest for the same reason that the
SplitTable() logic doesn't set attributes
on descriptors of type EfiRuntimeServicesData or other memory types. The
purpose of the SplitTable() function
is to use the input image records to split descriptors so each ima
On 4/17/2024 2:41 PM, Oliver Smith-Denny wrote:
Now, for the case of ARM64, where you have 64k runtime
granularity and often will end up with the case of many
extra pages in a code section, those pages will be marked
as RO and executable, even though they contain garbage. I think
it would be w
On 4/17/2024 9:52 AM, Ard Biesheuvel wrote:
So the purpose of the MAT is to describe RT code (and to a lesser
extent, RT data) regions where we cannot apply either RO or XP to the
whole thing. IIRC there was never an intent to exhaustively describe
all memory runtime regions. Also note that RO wa
On 4/17/2024 7:34 AM, Taylor Beebe wrote:
On 4/17/2024 7:09 AM, Oliver Smith-Denny wrote:
On 4/17/2024 7:05 AM, Taylor Beebe wrote:
On 4/17/2024 6:40 AM, Oliver Smith-Denny wrote:
Aside from this, I wonder if we can be more aspirational here. These
EfiRuntimeServicesCode regions without attr
FYI you can have much larger files in the newer version of the filesystem. See
EFI_COMMON_SECTION_HEADER2
https://uefi.org/specs/PI/1.8A/V3_Code_Definitions.html#firmware-file-system
https://uefi.org/specs/PI/1.8A/V3_Code_Definitions.html#firmware-file-section
Thanks,
Andrew Fish
> On Apr 3, 2
Hi, John
Can you show how do you add your FV?
[FV.MY_FV]
balabala
I cannot find a way to insert a linux.efi and initrd into FV. But I see you
success.
If you are willing, your work on this post will be very meaningful. Can you
write a blog with all the steps?
Thank you very much!
Charlley
-
EFI_RESOURCE_MEMORY_UNACCEPTED has been officially defined in the PI
1.8 specification. So all temporary solutions have been replaced with
the actual definition.
Cc: Felix Polyudov
Cc: Dhanaraj V
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Cc: Erdem Aktas
Cc: Min Xu
Cc: Tom Lendacky
Hi JP,
Is there a reason switch BSP is being used. That is not a common operation
and is typically used if the current BSP is not stable or there is a good
reason to switch the BSP for OS boot.
The MP Services can be used to execute a C function on APs to execute
MSR related instructions.
Mike
> -Original Message-
> From: Jayaprakash, N
> Sent: Tuesday, April 9, 2024 11:09 PM
> To: devel@edk2.groups.io; Jayaprakash, N
> Cc: Rebecca Cran ; Kinney, Michael D
>
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc: wrmsr
> function available in edk2module is not working
On Wed, Apr 17, 2024 at 10:08 AM Ard Biesheuvel wrote:
>
> (cc Jiewen)
>
> Please cc the OVMF maintainers when you send edk2 patches. (There is a
> Maintainers file in the root of the repo)
Thanks, I added everyone returned from the GetMaintainer.py script.
> On Wed, 17 Apr 2024 at 18:54, Adam D
(cc Jiewen)
Please cc the OVMF maintainers when you send edk2 patches. (There is a
Maintainers file in the root of the repo)
On Wed, 17 Apr 2024 at 18:54, Adam Dunlap via groups.io
wrote:
>
> Ensure that when a #VC exception happens, the instruction at the
> instruction pointer matches the inst
Ensure that when a #VC exception happens, the instruction at the
instruction pointer matches the instruction that is expected given the
error code. This is to mitigate the ahoi WeSee attack [1] that could
allow hypervisors to breach integrity and confidentiality of the
firmware by maliciously injec
On Wed, 17 Apr 2024 at 16:34, Taylor Beebe wrote:
>
>
> On 4/17/2024 7:09 AM, Oliver Smith-Denny wrote:
> > On 4/17/2024 7:05 AM, Taylor Beebe wrote:
> >>
> >> On 4/17/2024 6:40 AM, Oliver Smith-Denny wrote:
> >>> Aside from this, I wonder if we can be more aspirational here. These
> >>> EfiRuntim
On 4/17/2024 7:09 AM, Oliver Smith-Denny wrote:
On 4/17/2024 7:05 AM, Taylor Beebe wrote:
On 4/17/2024 6:40 AM, Oliver Smith-Denny wrote:
Aside from this, I wonder if we can be more aspirational here. These
EfiRuntimeServicesCode regions without attributes set are, if I am
understanding corr
On 4/17/2024 7:05 AM, Taylor Beebe wrote:
On 4/17/2024 6:40 AM, Oliver Smith-Denny wrote:
Aside from this, I wonder if we can be more aspirational here. These
EfiRuntimeServicesCode regions without attributes set are, if I am
understanding correctly, from loaded images.
These EfiRuntimeServic
On 4/17/2024 6:40 AM, Oliver Smith-Denny wrote:
Hi Ard,
On 4/16/2024 11:38 PM, Ard Biesheuvel wrote:
For entries where we lack such additional metadata, I don't think we
can make assumptions based on the type beyond mapping data and MMIO
regions XP. We have no idea how those EfiRuntimeServic
Hi Taylor,
Thanks for your update.
After test, issue can be fixed by your patch.
But why we not set the EFI_MEMORY_XP or EFI_MEMORY_RO attribute in SplitRecord
API?
If we set the attribute in the beginning of the NewRecord created, it seems we
don’t need to EnforceMemoryMapAttribute later?
Best
Hi Ard,
On 4/16/2024 11:38 PM, Ard Biesheuvel wrote:
For entries where we lack such additional metadata, I don't think we
can make assumptions based on the type beyond mapping data and MMIO
regions XP. We have no idea how those EfiRuntimeServicesCode regions
may be used, and currently, the spec
That is good start. The SMRAM lock and Flash lock seem good to me.
Comment:
1) Do we really need to add "Q35" for the policy?
#define VIRT_HSTI_BYTE0_Q35_SMM_SMRAM_LOCK BIT0
#define VIRT_HSTI_BYTE0_Q35_SMM_SECURE_VARS_FLASH BIT1
I feel we had better remove it, since SMM_SMRAM_LOCK and SM
Ashraf:
I just merge it.
Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io 代表 Ashraf Ali S
> 发送时间: 2024年4月17日 16:36
> 收件人: devel@edk2.groups.io; S, Ashraf Ali ;
Chen,
> Christine ; Rebecca Cran ;
> Liming Gao
> 抄送: Feng, Bob C ; Chaganty, Rangasai V
>
> 主题: Re: [edk2-devel] [PATCH]
On Wed, 17 Apr 2024 at 10:18, Gerd Hoffmann wrote:
>
> On Fri, Mar 22, 2024 at 03:27:31PM +0100, Gerd Hoffmann wrote:
> >
> >
> > Gerd Hoffmann (2):
> > OvmfPkg/VirtHstiDxe: add varstore flash check
> > OvmfPkg/VirtHstiDxe: add code flash check
> >
> > Konstantin Kostiuk (2):
> > OvmfPkg: Ad
To align the CPU topology information recognized by the operating system
with the CPU topology information configured by QEMU, we need to get the
information of topology to have complex PPTT tables setups.
When creating the pptt table, we considered the cluster layer,
SBSA Reference Platform ha
To align the CPU topology information recognized by the operating system with
the CPU topology
information configured by QEMU, we need to make use of the CPU topology
information to create
complex PPTT tables setups.
We can get the CPU topology information via SMC.
Signed-off-by: Xiong Yining
Provide functions to check for CPU topology information:
- the number of sockets on sbsa-ref platform.
- the number of clusters in one socket.
- the number of cores in one cluster.
- the number of threads in one cores.
As SMC calls can return up to 4 return values. the number of
sockets, clusters
Hi Gerd,
Thanks,
Chao
On 2024/4/17 17:35, Gerd Hoffmann wrote:
On Wed, Apr 17, 2024 at 04:12:56PM +0800, Chao Li wrote:
Patch1: Added three PCDs for QemuFwCfgLibMmio
Patch2: Sparate QemuFwCfgLibMmio.c into two files and default as DXE
stage library.
Patch3: Added QemuFwCfgMmiLib PEI version
Pa
On Wed, Apr 17, 2024 at 04:12:56PM +0800, Chao Li wrote:
> Patch1: Added three PCDs for QemuFwCfgLibMmio
> Patch2: Sparate QemuFwCfgLibMmio.c into two files and default as DXE
> stage library.
> Patch3: Added QemuFwCfgMmiLib PEI version
> Patch4: Rename QemuFwCfgLibMmio.inf to QemuFwCfgMmioDxeLib.i
From: Min M Xu
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4756
There are below updates in this patch:
1. Rename README to README.md so that it can be show as markdown
document.
2. Update some information about TDVF.
2. Fix some typo.
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Signed-off-by:
Hi @Liming Gao @Rebecca Cran
Is this patch already pushed? As its been already reviewed.
Thanks.,
S, Ashraf Ali
-Original Message-
From: devel@edk2.groups.io On Behalf Of Ashraf Ali S
Sent: Monday, March 11, 2024 5:01 PM
To: devel@edk2.groups.io; Chen, Christine
Cc: Rebecca Cran ; Limi
On Fri, Mar 22, 2024 at 03:27:31PM +0100, Gerd Hoffmann wrote:
>
>
> Gerd Hoffmann (2):
> OvmfPkg/VirtHstiDxe: add varstore flash check
> OvmfPkg/VirtHstiDxe: add code flash check
>
> Konstantin Kostiuk (2):
> OvmfPkg: Add VirtHstiDxe driver
> OvmfPkg: Add VirtHstiDxe to OVMF firmware bu
Added the PEI stage library for QemuFwCfgMmioLib, which uses the FDT to
find the fw_cfg and parse it.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Co-authored-by: Xianglai Li
Signed-off-by: Chao Li
---
.../Library/QemuFwCfgLib/Q
Rename QemuFwCfgLibMmio.inf to QemuFwCfgMmioDxeLib.inf, and enable the
new name in the AARCH64 and RISCV64 virtual machines.
Build-tested only (with "ArmVirtQemu.dsc and RiscVVirtQemu.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoff
Separate QemuFwCfgLibMmio.c into two files named QemuFwCfgLibMmio.c and
QemuFwCfgLibMmioDxe.c, added a new header named
QemuFwCfgLibMmioInternal.h for MMIO version.
Build-tested only (with "ArmVirtQemu.dsc and RiscVVirtQemu.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
Cc: Ard B
Added three PCDs named PcdFwCfgSelectorAddress, PcdFwCfgDataAddress and
PcdFwCfgDmaAddress, all of type PcdsDynamic and PcdDynamicEx, whcih will
be used in QemuFwCfgLibMmio version to replace the three global
variables in QemuFwCfgLib.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
Cc: A
Patch1: Added three PCDs for QemuFwCfgLibMmio
Patch2: Sparate QemuFwCfgLibMmio.c into two files and default as DXE
stage library.
Patch3: Added QemuFwCfgMmiLib PEI version
Patch4: Rename QemuFwCfgLibMmio.inf to QemuFwCfgMmioDxeLib.inf and
enable it in AARCH64 and RISCV64.
BZ: https://bugzilla.tian
On Wed, Apr 17, 2024 at 03:43:30PM +0800, Chao Li wrote:
> Hi Gerd,
>
>
> Thanks,
> Chao
> On 2024/4/17 14:59, Gerd Hoffmann wrote:
> > On Wed, Apr 17, 2024 at 10:53:21AM +0800, Chao Li wrote:
> > > Hi Gerd,
> > >
> > > Part 2 has been be merged, I'm separating this Lib into two serve the PEI
>
I'm using the OVMF library, haven't try the AMD library:).
> -Original Message-
> From: Gerd Hoffmann
> Sent: Wednesday, April 17, 2024 3:04 PM
> To: Wu, Jiaxin
> Cc: thomas.lenda...@amd.com; devel@edk2.groups.io; Ni, Ray
> ; Zeng, Star ; Ard Biesheuvel
> ; Yao, Jiewen ; Kumar,
> Rahul R
Hi Gerd,
Thanks,
Chao
On 2024/4/17 14:59, Gerd Hoffmann wrote:
On Wed, Apr 17, 2024 at 10:53:21AM +0800, Chao Li wrote:
Hi Gerd,
Part 2 has been be merged, I'm separating this Lib into two serve the PEI
stage and DXE stage.
Currently, This DXE library uses three global variables, and when I
On Tue, Apr 16, 2024 at 03:40:08PM +, Yao, Jiewen wrote:
> Yeah, I also considered that before. But after look at current code
> structure, I give up.
>
> Since following SEV component are NOT in AmdSev directory (especially the TCG
> one), I do not see a strong reason to put them to IntelTd
1.Xilinx RC is XDMA
2.Support NVME storage
Nvme storage needs to be formatted to FAT32 format.
Reviewed-by: Ran Wang
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Sunil V L
Cc: Daniel Schaefer
Signed-off-by: Yang Wang
---
.../XiangshanSeriesPkg/NanhuDev/NanhuDev.dsc | 30 +-
.../XiangshanS
This commit adds the initial support for BOSC's
nanhu platform which provides up to 2 RISC-V RV64
processor cores.
Signed-off-by: Yang Wang
Signed-off-by: Ran Wang
Signed-off-by: YunFeng Yang
Signed-off-by: YaXing Guo
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Sunil V L
Cc: Daniel Schaefer
On Tue, Apr 16, 2024 at 11:34:00AM +, Wu, Jiaxin wrote:
> Hi Gerd,
>
> > Is the SmmRelocationLib approach supposed to work with mixed mode
> > firmware where PEI is running in ia32 mode and dxe/smm is running
> > in x64 mode (i.e. OvmfPkg/OvmfPkgIa32X64.dsc)?
>
> Yes, I passed the test on the
62 matches
Mail list logo
