Null SmmAccessLib is confusing to me. Have you evaluated the option:
Create two instances of BoardInitLib for pre-mem and post-mem. Pre-mem
one doesn’t link to SmmAccessLib
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Michael Kubacki
> Sent: Friday, August 20, 2021
> -Original Message-
> From: zhoucheng
> Sent: Thursday, August 19, 2021 3:31 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Wu, Hao A ; Liming
> Gao
> Subject: [PATCH v1 2/2] MdeModulePkg:Increase Nvme capacity display
>
> Displays the Nvme total capacity.
>
> Signed-off-by: Cheng Zhou
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of
> zhoucheng
> Sent: Thursday, August 19, 2021 3:31 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Liming Gao
> ; Liu, Zhiguang
> Subject: [edk2-devel] [PATCH v1 1/2] MdePkg:Update
> IndustryStandard/Nvme.h with Nvme
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of
> Grzegorz Bernacki
> Sent: Wednesday, August 18, 2021 3:36 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A ;
> samer.el-haj-mahm...@arm.com; sunny.w...@arm.com;
> m...@semihalf.com; upstr...@semihalf.com;
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Marvin
> H?user
> Sent: Monday, August 16, 2021 4:12 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Vitaly Cheptsov
> Subject: [edk2-devel] [PATCH V2 3/3] MdeModulePkg: Consume new
>
> -Original Message-
> From: Marvin Häuser
> Sent: Monday, August 16, 2021 4:12 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray
> Subject: [PATCH V2 1/3] MdeModulePkg: Rename IS_ALIGNED macros to
> avoid name collisions
>
> This patch is a preparation for the
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Marvin
> H?user
> Sent: Monday, August 16, 2021 4:12 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A ;
> Vitaly Cheptsov
> Subject: [edk2-devel] [PATCH 1/1] MdeModulePkg/EbcDxe: Mitigate
> memcpy intrinsics
>
>
> -Original Message-
> From: Michael Kubacki
> Sent: Saturday, August 14, 2021 4:02 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A ;
> Bi, Dandan ; Liming Gao
> ; De, Debkumar ;
> Han, Harry ; West, Catharine
> ; Marvin Häuser
> Subject: [PATCH v1 1/1] MdeModulePkg/PeiCore:
The existing code fails to create/finish configuring the
pcie subsystem if it fails to get a linkup. This is reasonable
on the RPi4 because it generally won't happen, and the OS
could not see the root port. Now that the OS can see the
root port, its a bit odd if it only shows up when
something is
Lets prepare to switch between XHCI and PCI by moving
the XHCI definition into its own SSDT. That way we can
select it based on the menu settings. The resource
producer/consumer flag is also corrected.
Reviewed-by: Andrei Warkentin
Signed-off-by: Jeremy Linton
---
Arm has standardized a PCI SMC conduit that can be used
to access the PCI config space in a standardized way. This
functionality doesn't yet exist in many OS/Distro's. Lets
add another advanced config item that allows the user
to toggle between presenting the XHCI on the base RPi4
as a platform
Linux, for the time being has refused to support the Arm
standard SMCCC for PCIe configuration. Instead they
want to continue to maintain per device "quirks".
As the RPI isn't really ECAM this is a bit more
involved because the MCFG can't really describe
the root port+config registers situation.
A new Arm standard DEN0115A specifies how platforms that don't have
standard ECAM can use the firmware to handle config read/write
operations. This is mostly implemented in TFA but UEFI needs to assure
that there is a description of the root complex in the ACPI namespace.
This set adds that
The CM4 has an actual PCIe slot, so the device filtering
need to be a little less restrictive WRT busses with more
than 1 device given that switches can now appear in the
topology. Since it is possible to start numbering the
busses with a non-zero value, the bus restriction should
be based on the
The CM4 has a number of carrier boards with PCIe
slots. With the PCIe changes in place its quite
possible to utilize a NVMe root device. Lets allow
people to boot from it.
Reviewed-by: Andrei Warkentin
Signed-off-by: Jeremy Linton
---
Platform/RaspberryPi/RPi4/RPi4.dsc | 5 +
Since we plan on toggling between XHCI and PCI the PCI
root needs to be in its own SSDT. This is all thats needed
of UEFI. The SMC conduit is provided directly to the running
OS. When the OS detects this PCIe port on a machine without
a MCFG it attempts to connect to the SMC conduit. The RPi
That's a good point. We were mostly considering this for on-chip PCI
devices. I will rework this in v2.
Thanks,
Michael
On 8/19/2021 8:55 PM, Michael D Kinney wrote:
Hi Michael,
Using S/B/D/F is not a good way to provide this information.
It can change based when other PCI devices are
Hi Michael,
These all look like reasonable changes to me.
Acked-by: Michael D Kinney
Mike
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Michael Kubacki
> Sent: Thursday, August 5, 2021 9:38 AM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Desimone, Nathaniel L
> ;
Hi Michael,
Using S/B/D/F is not a good way to provide this information.
It can change based when other PCI devices are enabled/disabled/added/removed.
It is better to use a list of D/F similar to PCI Device Paths or just
use a PCI device path.
Mike
> -Original Message-
> From:
Acked-by: Michael Kubacki
On 8/18/2021 2:49 PM, Benjamin Doron wrote:
Cc: Nate DeSimone
Cc: Isaac Oram
Cc: Michael Kubacki
Signed-off-by: Benjamin Doron
---
Platform/Intel/Readme.md | 8
1 file changed, 8 insertions(+)
diff --git a/Platform/Intel/Readme.md
Acked-by: Michael Kubacki
On 8/18/2021 2:49 PM, Benjamin Doron wrote:
Cc: Nate DeSimone
Cc: Isaac Oram
Cc: Michael Kubacki
Signed-off-by: Benjamin Doron
---
Maintainers.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Maintainers.txt b/Maintainers.txt
index
Reviewed-by: Michael Kubacki
Carrying forward R-b from v2.
On 8/18/2021 2:48 PM, Benjamin Doron wrote:
Note that the SKU IDs do not represent register values, they were chosen
somewhat arbitrarily. We perform the mapping ourselves, so the
definitions can be changed.
Cc: Chasel Chiu
Cc: Nate
Reviewed-by: Michael Kubacki
Carrying forward R-b from v2.
On 8/18/2021 2:48 PM, Benjamin Doron wrote:
This makes diffing the follow-up board changes in these files easier.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Isaac Oram
Cc: Michael Kubacki
Signed-off-by: Benjamin Doron
---
EcRead() should have EFI_INVALID_PARAMETER listed as a return value. I
don't think you need to generate a new series for that but I will defer
to Nate.
Reviewed-by: Michael Kubacki
On 8/18/2021 2:48 PM, Benjamin Doron wrote:
Add EC read (0x80) and write (0x81) commands, as defined by ACPI.
Hi,
On 8/17/21 10:09 AM, Ard Biesheuvel wrote:
On Tue, 10 Aug 2021 at 05:36, Jeremy Linton wrote:
A new Arm standard DEN0115A specifies how
platforms that don't have standard ECAM can
use the firmware to handle config read/write
operations. This is mostly implemented in TFA
but UEFI needs to
This patch proposes Carolyn Gjertsen as maintainer of edk2-test
repository and Supreeth Venkatesh as reviewer from AMD.
Signed-off-by: Supreeth Venkatesh
---
uefi-sct/Maintainers.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/uefi-sct/Maintainers.txt b/uefi-sct/Maintainers.txt
index
Hi Pedro,
1) SuperBlock.c: The following #include was added, but should not be required:
#include "Uefi/UefiBaseType.h"
2) Inode.c - Ext4Read() - Has DEBUG() macro before local variable declarations.
Best regards,
Mike
> -Original Message-
> From: devel@edk2.groups.io On Behalf
This patch-series addresses bugs found when testing the filesystem with
more complex usage of the file protocol, particularly through the shell
itself.
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Bret Barkelew
Pedro Falcato (3):
Ext4Pkg: Fix incorrect usage of Ext4InitExtentsMap.
Ext4Pkg:
This helps us track directories and directory entries,
which helps us getting a general idea of how the filesystem
looks. In the future, it might serve as a directory cache.
Right now, it only lets us know which name "." and ".." may refer
to, which fixes a EFI_FILE_PROTOCOL::GetInfo() bug that
This makes it so callers that may expect FAT32 filesystems (most do)
have more normal looking ReadDir() results.
This commit also presents a better filename for files opened through
Open(".").
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Bret Barkelew
Signed-off-by: Pedro Falcato
---
Fixes bug triggered by ShellPkg code, in usage of EFI_FILE_PROTOCOL's
Open().
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Bret Barkelew
Signed-off-by: Pedro Falcato
---
Features/Ext4Pkg/Ext4Dxe/File.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff
Ray,
In the end, PI modules are allowed to depend on non-deprecated PI PPIs.
The scope of this change is about the API that installs the PPI. So I do
not want to diverge the conversation about changing other code to avoid
the PPI.
I've already been waiting since April to get other
I don't understand your argument.
The library class (SmmAccessLib) that already exists is the abstraction
layer. This is not introducing a new layer of abstraction. It is using
the current layer of abstraction.
Thanks,
Michael
On 8/19/2021 5:49 AM, Ni, Ray wrote:
Michael,
I don’t think
Hi Steven,
Thank you for helping send the patches.
I think the request is to add the
https://github.com/alyssachne/edk2/tree/2021-gsoc-llvm-gnumake-v3
branch to edk2-staging repository once the review of these 2 patches are
complete. Correct?
That branch is based on very recent edk2/master
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCELLED
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Asia/Shanghai
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Shanghai
X-LIC-LOCATION:Asia/Shanghai
BEGIN:STANDARD
TZNAME:CST
On Fri, Aug 13, 2021 at 02:13:02PM +0800, Gary Lin wrote:
> Without QemuKernelLoaderFsDxe, QemuLoadKernelImage() couldn't download
> the kernel, initrd, and kernel command line from QEMU's fw_cfg.
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links:
On Fri, Aug 13, 2021 at 02:13:01PM +0800, Gary Lin wrote:
> There are several functions in OvmfPkg/Library using
> QemuFwCfgS3Enabled() to detect the S3 support status. However, in
> MdeModulePkg, PcdAcpiS3Enable is used to check S3 support. Since
> InitializeXenPlatform() didn't set
On August 19, 2021 2:50 PM, Gerd Hoffmann wrote:
> > +/**
> > + In Tdx guest, some information need to be passed from host VMM to
> guest
> > + firmware. For example, the memory resource, etc. These information are
> > + prepared by host VMM and put in HobList which is described in
>
Do you want to open/close/lock SMRAM? If yes, then you need PPI.
If no, then you don’t need PPI. Hob should be enough to provide such info.
Thank you
Yao Jiewen
> -Original Message-
> From: Ni, Ray
> Sent: Thursday, August 19, 2021 6:02 PM
> To: Yao, Jiewen ; Michael Kubacki
> ;
Reviewed-by: Min Xu
> -Original Message-
> From: Brijesh Singh
> Sent: Tuesday, August 17, 2021 9:47 PM
> To: devel@edk2.groups.io
> Cc: James Bottomley ; Xu, Min M
> ; Yao, Jiewen ; Tom Lendacky
> ; Justen, Jordan L ;
> Ard Biesheuvel ; Erdem Aktas
> ; Michael Roth ; Brijesh
> Singh
>
Reviewed-by: Min Xu
> -Original Message-
> From: Brijesh Singh
> Sent: Tuesday, August 17, 2021 9:47 PM
> To: devel@edk2.groups.io
> Cc: James Bottomley ; Xu, Min M
> ; Yao, Jiewen ; Tom Lendacky
> ; Justen, Jordan L ;
> Ard Biesheuvel ; Erdem Aktas
> ; Michael Roth ; Brijesh
> Singh
>
Reviewed-by: Min Xu
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Brijesh
> Singh via groups.io
> Sent: Tuesday, August 17, 2021 9:47 PM
> To: devel@edk2.groups.io
> Cc: James Bottomley ; Xu, Min M
> ; Yao, Jiewen ; Tom Lendacky
> ; Justen, Jordan L ;
> Ard Biesheuvel ;
From: Ashish Kalra
Check for SEV live migration feature support, if detected
setup a new UEFI enviroment variable to indicate OVMF
support for SEV live migration.
This environment variable is created by UEFI but consumed
by the (guest) linux kernel. This is actually part of a
3-way negotiation
From: Ashish Kalra
Mark the SEC GHCB page (that is mapped as unencrypted in
ResetVector code) in the hypervisor's guest page encryption
state tracking.
Cc: Jordan Justen
Cc: Ard Biesheuvel
Signed-off-by: Ashish Kalra
---
OvmfPkg/PlatformPei/AmdSev.c | 11 +++
1 file changed, 11
From: Ashish Kalra
Make the #VC handler aware of the page encryption state
change hypercall by adding support to check KVM_HC_MAP_GPA_RANGE
hypercall and add the additional register values used by
hypercall in the GHCB.
Cc: Jordan Justen
Cc: Ard Biesheuvel
Signed-off-by: Ashish Kalra
---
From: Ashish Kalra
Invoke the hypercall API to notify hypervisor when the page's
encryption state changes.
Cc: Jordan Justen
Cc: Ard Biesheuvel
Signed-off-by: Brijesh Singh
Signed-off-by: Ashish Kalra
---
OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c | 20
From: Ashish Kalra
Add API to issue hypercall on page encryption state change.
By default all the SEV guest memory regions are considered encrypted,
if a guest changes the encryption attribute of the page (e.g mark a
page as decrypted) then notify hypervisor. Hypervisor will need to
track the
From: Ashish Kalra
Add support to check if we are running inside KVM HVM and
KVM HVM supports SEV Live Migration feature.
Cc: Jordan Justen
Cc: Ard Biesheuvel
Signed-off-by: Ashish Kalra
---
OvmfPkg/Include/Library/MemEncryptSevLib.h| 12
+
From: Ashish Kalra
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3467
By default all the SEV guest memory regions are considered encrypted,
if a guest changes the encryption attribute of the page (e.g mark a
page as decrypted) then notify hypervisor. Hypervisor will need to
track the
> + CpuIdMapPtr->AcpiProcessorId = (ProcessorInfoBuffer.Location.Package
> << mNumOfBitShift) +
> (UINT32)ProcessorInfoBuffer.ProcessorId;
1. I don't understand this assignment. Since you will re-assign this later, why
not remove this assignment?
> +
> + //make sure 1st entry is BSP
> +
On August 19, 2021 2:31 PM, Gerd Hoffmann wrote:
> > > IIRC some of the TDX features require a separate firmware binary.
> > > So, if we need a separate binary anyway at some point in the future,
> > > isn't it simpler then to use a separate firmware binary right from the
> > > start?
> > >
> > >
Jiewen,
We have MmAccess PPI and gEfiMmPeiSmramMemoryReserveGuid HOB.
If Standalone IPL can get the SMRAM range from the HOB, what's the purpose of
MmAccess PPI?
X86 silicon doesn't rely on MmAccess.Close/Lock to close SMRAM anymore. Does
ARM need?
Michael,
Have you considered to remove the
Michael,
I don’t think scenario #1 is a good reason for NULL instance of SmmAccessLib.
The root cause is BoardInitLib lib class supports pre-mem and post-mem board
init.
Below solution can avoid NULL SmmAccessLib:
Create two instances of BoardInitLib for pre-mem and post-mem. Pre-mem one
On 8/16/21 9:18 AM, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
> ---
> Maintainers.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 2e2d4d1b7f77..694994b4bfae 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -145,6
On 8/19/21 10:11 AM, Gerd Hoffmann wrote:
> Prefer the e820 map provided via qemu firmware config interface
> for memory detection. Use rtc cmos only as fallback, which should
> be rarely needed these days as qemu supports etc/e820 since 2013.
>
> Signed-off-by: Gerd Hoffmann
> ---
>
On 8/19/21 9:25 AM, Gerd Hoffmann wrote:
> This little series adds virtio 1.0 support for the virtio-mmio
> transport. For the mmio transport the difference between 0.9.5 and 1.0
> is rather small (when compared to the pci transport), it is just a bunch
> of new registers for the changed virtio
MdePkg:Update IndustryStandard/Nvme.h with Nvme amdin controller data
Add the definition of Nvme total capacity in Nvme structure.
zhoucheng (2):
MdePkg:Update IndustryStandard/Nvme.h with Nvme amdin controller data
MdeModulePkg:Increase Nvme capacity display
Update Nvme data structure
Signed-off-by: Cheng Zhou
Reviewed-by: Liming Gao
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
---
MdePkg/Include/IndustryStandard/Nvme.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git
Displays the Nvme total capacity.
Signed-off-by: Cheng Zhou
Reviewed-by: Hao A Wu
Cc: Ray Ni
Cc: Hao A Wu
Cc: Liming Gao
---
MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
Don't use cmos for memory detection if possible.
qemu provides the etc/e820 firmware config file
as alternative since 2013.
Gerd Hoffmann (2):
OvmfPkg/PlatformPei: ScanOrAdd64BitE820Ram improvements
OvmfPkg/PlatformPei: prefer etc/e820 for memory detection
OvmfPkg/PlatformPei/MemDetect.c |
Prefer the e820 map provided via qemu firmware config interface
for memory detection. Use rtc cmos only as fallback, which should
be rarely needed these days as qemu supports etc/e820 since 2013.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/PlatformPei/MemDetect.c | 15 ---
1 file
Add a bool parameter to ScanOrAdd64BitE820Ram to explicitly specify
whenever ScanOrAdd64BitE820Ram should add HOBs for high memory (above
4G) or scan only.
Also add a lowmem parameter so ScanOrAdd64BitE820Ram
can report the memory size below 4G.
This allows a more flexible usage of
Now with everything in place for virtio 1.0 devices we can let
VirtioMmioInit() return SUCCESS.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Use QueueNumMax as QueueNum default for drivers which do not
explicitly call VIRTIO_DEVICE_PROTOCOL->SetQueueSize().
Signed-off-by: Gerd Hoffmann
---
.../Library/VirtioMmioDeviceLib/VirtioMmioDevice.h | 1 +
.../VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c | 12 +++-
2 files
virtio 1.0 has 64 feature bits instead of 32.
Signed-off-by: Gerd Hoffmann
---
.../VirtioMmioDeviceFunctions.c | 28 +++
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c
Add #defines for the Version field. Read and store the version,
log the version found as info message.
Continue to return UNSUPPORTED for now, we need some more patches
to complete virtio 1.0 support first.
Signed-off-by: Gerd Hoffmann
---
.../VirtioMmioDeviceLib/VirtioMmioDevice.h | 4
Virtio 1.0 allows a more flexible virtio ring layout, so we have to set
addresses for descriptors avail flags and use flags separately. We
continue to use a ring layout compatible with virtio 0.9.5 though, so no
other changes are needed to setup the virtio queues.
Signed-off-by: Gerd Hoffmann
Nothing to do here for virtio 1.0 devices.
Signed-off-by: Gerd Hoffmann
---
.../Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c
This little series adds virtio 1.0 support for the virtio-mmio
transport. For the mmio transport the difference between 0.9.5 and 1.0
is rather small (when compared to the pci transport), it is just a bunch
of new registers for the changed virtio queue initialization. So the
patch series is
Add defines for the config space offsets for virtio 1.0 mmio transport.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Philippe Mathieu-Daude
---
OvmfPkg/Include/IndustryStandard/Virtio10.h | 12
1 file changed, 12 insertions(+)
diff --git a/OvmfPkg/Include/IndustryStandard/Virtio10.h
Hi,
> +/**
> + In Tdx guest, some information need to be passed from host VMM to guest
> + firmware. For example, the memory resource, etc. These information are
> + prepared by host VMM and put in HobList which is described in TdxMetadata.
What kind of information is passed to the guest
Hi,
> > IIRC some of the TDX features require a separate firmware binary. So, if we
> > need a separate binary anyway at some point in the future, isn't it simpler
> > then
> > to use a separate firmware binary right from the start?
> >
> > You can simply add a Tdx-specific variant of the
72 matches
Mail list logo
