[edk2-devel] [PATCH 1/1] Maintainers.txt: Update my email address
From: Anthony PERARD Signed-off-by: Anthony PERARD --- Maintainers.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Maintainers.txt b/Maintainers.txt index 7d9cdca611fc..07fa50d65991 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -567,7 +567,7 @@ F: OvmfPkg/XenIoPvhDxe/ F: OvmfPkg/XenPlatformPei/ F: OvmfPkg/XenPvBlkDxe/ F: OvmfPkg/XenResetVector/ -R: Anthony Perard [tperard] +R: Anthony Perard [tperard] OvmfPkg: RISC-V Qemu Virt Platform F: OvmfPkg/RiscVVirt -- Anthony PERARD
Re: [edk2-devel] [PATCH] OvmfPkg: Set PcdCpuMaxLogicalProcessorNumber in OvmfXen
On Thu, Apr 25, 2024 at 11:42:01AM +0100, Alejandro Vallejo wrote: > Hi, > > On 25/04/2024 08:31, Gerd Hoffmann wrote: > > On Wed, Apr 24, 2024 at 02:36:32PM +0100, Alejandro Vallejo wrote: > >> Bump the compile-time constant for maximum processor count from 64 to 128 > >> in order to allow that many vCPUs to be brought online on Xen guests with > >> the default OVMF configuration. > > > >> + # UefiCpuPkg PCDs related to initial AP bringup and general AP > >> management. > >> + gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|128 > > > > Note that this is a dynamic PCD, so you can set it at runtime to the > > number of vcpus present in the VM. See MaxCpuCountInitialization() in > > OvmfPkg/PlatformPei/Platform.c for example. > > > > take care, > > Gerd > > > > Thanks for the heads up. Do you mean setting it at runtime through > fw_cfg? I saw PlatformMaxCpuCountInitialization() providing some > customizability, but Xen's toolstack doesn't provide fw_cfg at the > moment so it can't (as far as I've seen) use it. We don't need fw_cfg to set a PCD at runtime. It's a bit more complicated than setting it at build time, but we can always ask Xen how many vcpu we have and set the PCD accordingly. This is something that can happen in OvmfPkg/XenPlatformPei module. But to be honest, I don't know if it's worth it, because I don't know the downside of having a higher value for PcdCpuMaxLogicalProcessorNumber. Cheers, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118304): https://edk2.groups.io/g/devel/message/118304 Mute This Topic: https://groups.io/mt/105721898/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] OvmfPkg/OvmfXen: Fix S3
Hi Xenia, On Thu, Jul 13, 2023 at 01:47:12PM +0300, Xenia Ragiadakou wrote: > Currently, resuming an S3 suspended guest results in the following > assertion failure: > ASSERT > MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.c(41): > MemoryLength > 0 > This happens because some parts of the S3 suspend and resume paths > are missing in order for S3 to work. For instance, the variables > mS3AcpiReservedMemoryBase and mS3AcpiReservedMemoryBase are not > initialized, regions that are used on S3 resume are either missing > or not marked as ACPI NVS memory and can be corrupted by the OS. > This patch adds the missing parts based heavily on the existing S3 > implementation of other virtual platforms. > > For S3 support, the provision of fw_cfg is required in order for > suspend states to be retrieved. Is it possible to have S3 work without fw_cfg? We normally disable fw_cfg in QEMU when using it to start a Xen guest. We only enable fw_cfg if we want to boot a kernel directly in HVM (like PV guest, called Direct Kernel Boot in xl.cfg(5)). But even trying the direct kernel boot method, I've got issue trying to resume a suspended guest. I ran into: ASSERT /root/build/ovmf/UefiCpuPkg/Library/MpInitLib/MpLib.c(2093): (LibPcdGet64(9U) & (0x0001 | 0x0002)) == (0x0001 | 0x0002) By the way, I'm using `xl` to boot a guest to test this patch. So, I've got some question, which version of QEMU do you use, which work with this patch? What toolstack do you use to boot a guest? Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#108489): https://edk2.groups.io/g/devel/message/108489 Mute This Topic: https://groups.io/mt/100121295/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 3/4] OvmfPkg: Remove applicationProcessorEntryPoint
On Mon, Jul 10, 2023 at 11:17:05AM +0800, Zhiguang Liu wrote: > diff --git a/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm > b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm > index 56749bdbc9..67156d8252 100644 > --- a/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm > +++ b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm > @@ -39,23 +39,13 @@ xenPVHEntryPoint: > > BITS16 > ALIGN 16 > - > -applicationProcessorEntryPoint: > -; > -; Application Processors entry point > ; > -; GenFv generates code aligned on a 4k boundary which will jump to this > -; location. (0xffe0) This allows the Local APIC Startup IPI to be > -; used to wake up the application processors. > +; 0xffe0 > ; > -jmp EarlyApInitReal16 > - > -ALIGN 8 > - > -DD 0 > + DD 0, 0, 0 > > ; > -; The VTF signature > +; The VTF signature (0xffec) > ; > ; VTF-0 means that the VTF (Volume Top File) code does not require > ; any fixups. I've tested that part of the patch. OvmfXen seems to work fine with it: Acked-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#107167): https://edk2.groups.io/g/devel/message/107167 Mute This Topic: https://groups.io/mt/100051790/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 11/12] OvmfPkg/Xen: Replace the OVMF-specific SataControllerDxe
On Tue, May 09, 2023 at 05:32:11PM +0100, Pedro Falcato wrote: > Replace the OVMF-specific SataControllerDxe (to be later removed) with > the generic, MdeModulePkg one, for the OvmfXen platform. > > Cc: Ard Biesheuvel > Cc: Jiewen Yao > Cc: Jordan Justen > Cc: Gerd Hoffmann > Cc: Anthony Perard > Cc: Julien Grall > Signed-off-by: Pedro Falcato Acked-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#104799): https://edk2.groups.io/g/devel/message/104799 Mute This Topic: https://groups.io/mt/98787867/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v5 2/3] OvmfPkg/Xen: export AcpiTable installation into AcpiPlatformLib
On Thu, May 11, 2023 at 02:02:38PM +0200, Corvin Köhne wrote: > This makes the function reuseable by bhyve. > > Signed-off-by: Corvin Köhne > Acked-by: Gerd Hoffmann Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#104704): https://edk2.groups.io/g/devel/message/104704 Mute This Topic: https://groups.io/mt/98825806/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v5 1/3] OvmfPkg/Xen: export search of RSDP into a library function
On Thu, May 11, 2023 at 02:02:37PM +0200, Corvin Köhne wrote: > diff --git a/OvmfPkg/Library/AcpiPlatformLib/DxeAcpiPlatformLib.c > b/OvmfPkg/Library/AcpiPlatformLib/DxeAcpiPlatformLib.c > new file mode 100644 > index ..ce52ad31cf25 > --- /dev/null > +++ b/OvmfPkg/Library/AcpiPlatformLib/DxeAcpiPlatformLib.c > @@ -0,0 +1,62 @@ > +/** @file > + Copyright (c) 2023, Corvin Köhne As this new file move codes from OvmfPkg/XenAcpiPlatformDxe/Xen.c, shouldn't you also copy the "Copyright" lines from that file as well? Beside that, patch looks fine: Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#104703): https://edk2.groups.io/g/devel/message/104703 Mute This Topic: https://groups.io/mt/98825804/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 3/3] OvmfPkg/PlatformInitLib: simplify mtrr setup
On Tue, Mar 07, 2023 at 07:54:54AM +0100, Gerd Hoffmann wrote: > With the new mmconfig location at 0xe000 above the 32-bit PCI MMIO > window we don't have to special-case the mmconfig xbar any more. We'll > just add a mtrr uncachable entry starting at MMIO window base and ending > at 4GB. > > Update comments to match reality. > > Signed-off-by: Gerd Hoffmann Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#101969): https://edk2.groups.io/g/devel/message/101969 Mute This Topic: https://groups.io/mt/97444647/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 2/3] OvmfPkg/PlatformInitLib: move mmconfig to 0xe0000000
On Tue, Mar 07, 2023 at 07:54:53AM +0100, Gerd Hoffmann wrote:
> Also swap the ordering of 32bit PCI MMIO window on q35, i.e. use the
> room between end of low memory and the start of the mmconfig bar.
>
> With a typical configuration on modern qemu with gigabyte-aligned memory
> the MMIO window start at 0x800, sized 1532 MB. In case there is
> memory present above 0x8000 the window will start at 0xc000
> instead, with 512 MB size.
>
> This depends on qemu commit 4a4418369d6d ("q35: fix mmconfig and
> PCI0._CRS"), so it raises the bar for the lowest supported version
> to qemu 4.1 (released Aug 2019).
Maybe this new version requirement should be noted in OvmfPkg/README,
but I'm not sure were as it affect only machine started with Q35.
> diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
> index c328987e8432..18144d9a6d94 100644
> --- a/OvmfPkg/OvmfXen.dsc
> +++ b/OvmfPkg/OvmfXen.dsc
> @@ -434,7 +434,7 @@ [PcdsFixedAtBuild]
>#
># On Q35 machine types that QEMU intends to support in the long term, QEMU
># never lets the RAM below 4 GB exceed 2816 MB.
> - gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xB000
> + gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE000
Could you remove this change? OvmfXen doesn't use PlatformInitLib, and
we still have worked to do to be able to use Q35 in Xen guest.
I think the rest looks fine, so:
Reviewed-by: Anthony PERARD
Thanks,
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#101967): https://edk2.groups.io/g/devel/message/101967
Mute This Topic: https://groups.io/mt/97444650/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/3] OvmfPkg/PlatformInitLib: update address space layout comment
On Tue, Mar 07, 2023 at 07:54:52AM +0100, Gerd Hoffmann wrote: > Move the commment up so it is placed just before the address space > calculations start. Also add q35 memory layout. > > Signed-off-by: Gerd Hoffmann Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#101962): https://edk2.groups.io/g/devel/message/101962 Mute This Topic: https://groups.io/mt/97444649/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 1/1] OvmfPkg/OvmfXen: Build platform info HOB in XenPlatformPei
From: Anthony PERARD
Copy the function BuildPlatformInfoHob() from OvmfPkg/PlatformPei.
QemuFwCfgLib expect this HOB to be present, or fails to do anything.
InternalQemuFwCfgIsAvailable() from QemuFwCfgPeiLib module will not
check if the HOB is actually present for example and try to use a NULL
pointer.
Fixes: cda98df16228 ("OvmfPkg/QemuFwCfgLib: remove mQemuFwCfgSupported +
mQemuFwCfgDmaSupported")
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenPlatformPei/Platform.h | 1 +
OvmfPkg/XenPlatformPei/Platform.c | 20
2 files changed, 21 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
b/OvmfPkg/XenPlatformPei/Platform.h
index 039af50ffa32..7b4de128e713 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -12,6 +12,7 @@
#define _PLATFORM_PEI_H_INCLUDED_
#include
+#include
VOID
AddIoMemoryBaseSizeHob (
diff --git a/OvmfPkg/XenPlatformPei/Platform.c
b/OvmfPkg/XenPlatformPei/Platform.c
index 2d97a41ca78e..6c1886c158b5 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -17,6 +17,7 @@
//
// The Library classes this module consumes
//
+#include
#include
#include
#include
@@ -409,6 +410,20 @@ DebugDumpCmos (
}
}
+EFI_HOB_PLATFORM_INFO *
+BuildPlatformInfoHob (
+ VOID
+ )
+{
+ EFI_HOB_PLATFORM_INFO PlatformInfoHob;
+ EFI_HOB_GUID_TYPE *GuidHob;
+
+ ZeroMem (, sizeof PlatformInfoHob);
+ BuildGuidDataHob (, , sizeof
(EFI_HOB_PLATFORM_INFO));
+ GuidHob = GetFirstGuidHob ();
+ return (EFI_HOB_PLATFORM_INFO *)GET_GUID_HOB_DATA (GuidHob);
+}
+
/**
Perform Platform PEI initialization.
@@ -429,6 +444,11 @@ InitializeXenPlatform (
DEBUG ((DEBUG_INFO, "Platform PEIM Loaded\n"));
+ //
+ // Platform Info HOB used by QemuFw libraries
+ //
+ BuildPlatformInfoHob ();
+
DebugDumpCmos ();
if (!XenDetect ()) {
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97569): https://edk2.groups.io/g/devel/message/97569
Mute This Topic: https://groups.io/mt/95768201/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] Maintainers.txt: Change Anthony's github id
On Mon, Sep 19, 2022 at 05:01:48PM +, Kinney, Michael D wrote: > Reviewed-by: Michael D Kinney Hi, Could this patch be merged, or is something missing? Cheers, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97314): https://edk2.groups.io/g/devel/message/97314 Mute This Topic: https://groups.io/mt/93724802/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 3/3] OvmfPkg/OvmfXen: Introduce Xen's ResetSystemLib, to use xen hypercall
From: Anthony PERARD
When booting OvmfXen, the ACPI interface for shutdown/reset might not
be available, instead use the hypercall interface.
While it's probably possible to use the hypercall in all cases, we
keep using the same interface while it still possible. That is ACPI on
HVM guest, and fallback to hypercall on PVH guest.
Signed-off-by: Anthony PERARD
---
OvmfPkg/OvmfXen.dsc | 10 +++
...ystemLib.inf => BaseResetSystemLibXen.inf} | 9 ---
...SystemLib.inf => DxeResetSystemLibXen.inf} | 11 +---
...ResetShutdown.c => BaseResetShutdownXen.c} | 19 +++---
...eResetShutdown.c => DxeResetShutdownXen.c} | 26 ---
5 files changed, 49 insertions(+), 26 deletions(-)
copy OvmfPkg/Library/ResetSystemLib/{BaseResetSystemLib.inf =>
BaseResetSystemLibXen.inf} (73%)
copy OvmfPkg/Library/ResetSystemLib/{DxeResetSystemLib.inf =>
DxeResetSystemLibXen.inf} (73%)
copy OvmfPkg/Library/ResetSystemLib/{BaseResetShutdown.c =>
BaseResetShutdownXen.c} (72%)
copy OvmfPkg/Library/ResetSystemLib/{DxeResetShutdown.c =>
DxeResetShutdownXen.c} (72%)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 8df173a0ee84..18f7c0d76643 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -118,7 +118,7 @@ [SkuIds]
[LibraryClasses]
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
- ResetSystemLib|OvmfPkg/Library/ResetSystemLib/BaseResetSystemLib.inf
+ ResetSystemLib|OvmfPkg/Library/ResetSystemLib/BaseResetSystemLibXen.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
@@ -302,7 +302,7 @@ [LibraryClasses.common.DXE_CORE]
[LibraryClasses.common.DXE_RUNTIME_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.inf
+ ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLibXen.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
@@ -316,7 +316,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
[LibraryClasses.common.UEFI_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.inf
+ ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLibXen.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
@@ -326,7 +326,7 @@ [LibraryClasses.common.UEFI_DRIVER]
[LibraryClasses.common.DXE_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.inf
+ ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLibXen.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
@@ -345,7 +345,7 @@ [LibraryClasses.common.DXE_DRIVER]
[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.inf
+ ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLibXen.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
diff --git a/OvmfPkg/Library/ResetSystemLib/BaseResetSystemLib.inf
b/OvmfPkg/Library/ResetSystemLib/BaseResetSystemLibXen.inf
similarity index 73%
copy from OvmfPkg/Library/ResetSystemLib/BaseResetSystemLib.inf
copy to OvmfPkg/Library/ResetSystemLib/BaseResetSystemLibXen.inf
index 35d317f1e0b3..8d75dd565365 100644
--- a/OvmfPkg/Library/ResetSystemLib/BaseResetSystemLib.inf
+++ b/OvmfPkg/Library/ResetSystemLib/BaseResetSystemLibXen.inf
@@ -1,7 +1,9 @@
## @file
-# Base library instance for ResetSystem library class for OVMF
+# Base library instance for ResetSystem library class for Xen
#
# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2022, Citrix Systems, Inc.
+#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
@@ -9,7 +11,7 @@
[Defines]
INF_VERSION= 0x00010005
BASE_NAME = BaseResetSystemLib
- FILE_GUID = 66564872-21d4-4d2a-a68b-1e844f980820
+ FILE_GUID = 9ef32aa1-9e82-4fb1-9c49-0eff538601f8
MODULE_TYPE= BASE
VERSION_STRING
[edk2-devel] [PATCH 2/3] OvmfPkg/XenHypercallLib: Add SchedOp hypercall
From: Anthony PERARD
Add a new function to allow to make an hypercall to shutdown the
machine.
This import "sched.h" public header from Xen Project's repo. Some
changes have been made to be closer to EDK2's coding style.
Signed-off-by: Anthony PERARD
---
OvmfPkg/Include/IndustryStandard/Xen/sched.h | 50 +++
OvmfPkg/Include/Library/XenHypercallLib.h | 7 +++
.../Library/XenHypercallLib/XenHypercall.c| 14 ++
3 files changed, 71 insertions(+)
create mode 100644 OvmfPkg/Include/IndustryStandard/Xen/sched.h
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/sched.h
b/OvmfPkg/Include/IndustryStandard/Xen/sched.h
new file mode 100644
index ..b050354efe8d
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/Xen/sched.h
@@ -0,0 +1,50 @@
+/**
+ * sched.h
+ *
+ * Scheduler state interactions
+ *
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright (c) 2005, Keir Fraser
+ */
+
+#ifndef __XEN_PUBLIC_SCHED_H__
+#define __XEN_PUBLIC_SCHED_H__
+
+#include "event_channel.h"
+
+/*
+ * Halt execution of this domain (all VCPUs) and notify the system controller.
+ * @arg == pointer to sched_shutdown_t structure.
+ *
+ * If the sched_shutdown_t reason is SHUTDOWN_suspend then
+ * x86 PV guests must also set RDX (EDX for 32-bit guests) to the MFN
+ * of the guest's start info page. RDX/EDX is the third hypercall
+ * argument.
+ *
+ * In addition, which reason is SHUTDOWN_suspend this hypercall
+ * returns 1 if suspend was cancelled or the domain was merely
+ * checkpointed, and 0 if it is resuming in a new domain.
+ */
+#define XEN_SCHEDOP_SHUTDOWN 2
+
+struct _XEN_SCHED_SHUTDOWN {
+ unsigned intReason; /* SHUTDOWN_* => enum sched_shutdown_reason */
+};
+
+typedef struct _XEN_SCHED_SHUTDOWN XEN_SCHED_SHUTDOWN;
+DEFINE_XEN_GUEST_HANDLE (XEN_SCHED_SHUTDOWN);
+
+/*
+ * Reason codes for SCHEDOP_shutdown. These may be interpreted by control
+ * software to determine the appropriate action. For the most part, Xen does
+ * not care about the shutdown code.
+ */
+/* ` enum sched_shutdown_reason { */
+#define XEN_SHED_SHUTDOWN_POWEROFF 0 /* Domain exited normally. Clean up and
kill. */
+#define XEN_SHED_SHUTDOWN_REBOOT1 /* Clean up, kill, and then restart.
*/
+#define XEN_SHED_SHUTDOWN_SUSPEND 2 /* Clean up, save suspend info, kill.
*/
+#define XEN_SHED_SHUTDOWN_CRASH 3 /* Tell controller we've crashed.
*/
+#define XEN_SHED_SHUTDOWN_WATCHDOG 4 /* Restart because watchdog time
expired. */
+
+#endif /* __XEN_PUBLIC_SCHED_H__ */
diff --git a/OvmfPkg/Include/Library/XenHypercallLib.h
b/OvmfPkg/Include/Library/XenHypercallLib.h
index 28eee8ccac85..d7cf2c0c505b 100644
--- a/OvmfPkg/Include/Library/XenHypercallLib.h
+++ b/OvmfPkg/Include/Library/XenHypercallLib.h
@@ -101,4 +101,11 @@ XenHypercallEventChannelOp (
IN OUT VOID *Arguments
);
+INTN
+EFIAPI
+XenHypercallSchedOp (
+ IN INTN Operation,
+ IN OUT VOID *Arguments
+ );
+
#endif
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
b/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
index 65b14a11f402..b1a129998fdc 100644
--- a/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
@@ -87,3 +87,17 @@ XenHypercallEventChannelOp (
(INTN)Arguments
);
}
+
+INTN
+EFIAPI
+XenHypercallSchedOp (
+ IN INTN Operation,
+ IN OUT VOID *Arguments
+ )
+{
+ return XenHypercall2 (
+ __HYPERVISOR_sched_op,
+ Operation,
+ (INTN)Arguments
+ );
+}
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96303): https://edk2.groups.io/g/devel/message/96303
Mute This Topic: https://groups.io/mt/94960817/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 1/3] OvmfPkg: Introduce runtime XenHypercallLib
From: Anthony PERARD
We need a way to execute instruction "generated" at runtime from the
runtime library.
This patch introduce XenHypercallRuntimeLib, which is mostly a copy of
XenHypercallLib with a few changes.
We reserved some code space with "XenHypercallPage", which we will
overwrite to put the xen hypercall code. Then we ask Xen to overwrite
the reserved space with the hypercall page via `wrmsr`.
Allocation doesn't work, because the memory allocated at run time is
always considered to be data instead of code, so once Linux takes
over, we can't execute from it.
Signed-off-by: Anthony PERARD
---
Notes:
I've been told that we don't need to ask Xen on how to make hypercall
on x86, and that was just an helper to not have to figure out which
instruction to use. That would mean that instead of doing write_msr,
we would need a way to distinguish between AMD and Intel in order to
find out which instruction to use. So if this patch is too weird, that
another way to have hypercall in a runtime service.
OvmfPkg/OvmfXen.dsc | 1 +
.../XenHypercallRuntimeLib.inf| 46
.../XenHypercallLib/X86RuntimeXenHypercall.c | 210 ++
.../X64/RuntimeHypercallPage.nasm | 24 ++
4 files changed, 281 insertions(+)
create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallRuntimeLib.inf
create mode 100644 OvmfPkg/Library/XenHypercallLib/X86RuntimeXenHypercall.c
create mode 100644
OvmfPkg/Library/XenHypercallLib/X64/RuntimeHypercallPage.nasm
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 58a7c97cddf7..8df173a0ee84 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -312,6 +312,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
+ XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallRuntimeLib.inf
[LibraryClasses.common.UEFI_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallRuntimeLib.inf
b/OvmfPkg/Library/XenHypercallLib/XenHypercallRuntimeLib.inf
new file mode 100644
index ..07fdeb612760
--- /dev/null
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallRuntimeLib.inf
@@ -0,0 +1,46 @@
+## @file
+# Xen Hypercall abstraction lib for Intel for runtime services
+#
+# Copyright (c) 2014, Linaro Ltd. All rights reserved.
+# Copyright (c) 2022, Citrix Systems, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION= 0x00010005
+ BASE_NAME = XenHypercallRuntimeLib
+ FILE_GUID = f657a395-1d2c-40b5-bd34-eedc203899ab
+ MODULE_TYPE= DXE_RUNTIME_DRIVER
+ VERSION_STRING = 1.0
+ CONSTRUCTOR= XenHypercallRuntimeLibConstruct
+
+[Defines.IA32, Defines.X64]
+ LIBRARY_CLASS = XenHypercallLib|DXE_RUNTIME_DRIVER
+
+#
+# The following information is for reference only and not required by the
build tools.
+#
+# VALID_ARCHITECTURES = X64
+#
+
+[Sources.X64]
+ X86RuntimeXenHypercall.c
+ X64/hypercall.nasm
+ X64/RuntimeHypercallPage.nasm
+
+[Sources]
+ XenHypercall.c
+
+[Packages]
+ MdePkg/MdePkg.dec
+ OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+ BaseLib
+ DebugLib
+ UefiRuntimeLib
+
+[Guids.X64]
+ gEfiEventVirtualAddressChangeGuid # ALWAYS_CONSUMED
diff --git a/OvmfPkg/Library/XenHypercallLib/X86RuntimeXenHypercall.c
b/OvmfPkg/Library/XenHypercallLib/X86RuntimeXenHypercall.c
new file mode 100644
index ..d1c097e00f3a
--- /dev/null
+++ b/OvmfPkg/Library/XenHypercallLib/X86RuntimeXenHypercall.c
@@ -0,0 +1,210 @@
+/** @file
+ Xen Hypercall Library implementation for Intel architecture
+
+ Copyright (c) 2014, Linaro Ltd. All rights reserved.
+ Copyright (c) 2022, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+STATIC VOID *mHyperPage;
+
+//
+// Pointer to reserved page for Xen's hypercall page.
+//
+extern VOID *XenHypercallPage;
+
+//
+// Virtual Address Change Event
+//
+// This is needed for runtime variable access.
+//
+EFI_EVENT mXenHypercallLibAddrChangeEvent = NULL;
+
+RETURN_STATUS
+EFIAPI
+XenHypercallRuntimeLibConstruct (
+ IN EFI_HANDLEImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ XenHypercallLibInit ();
+
+ //
+ // We don't fail library construction, since that has catastrophic
+ // consequences for client modules (whereas those modules may easily be
+ // running on a non-Xen platform). Instead, XenHypercallIsAvailable()
+ // will return FALSE.
+ //
+ return RETURN_SUCCESS;
+}
+
+/**
+ Check if the X
[edk2-devel] [PATCH 0/3] OvmfXen: Fix machine shutdown in PVH guest
From: Anthony PERARD
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/ovmf.git
br.fix-pvh-shutdown-v2-v1
From: Anthony PERARD
Hi,
This series instroduce a XenHypercallLib that can be used at runtime by a EFI
service. And then it introduce a modified ResetSystemLib for Xen so we can use
the hypercall interface to shutdown a machine when the ACPI interface isn't
available.
Thanks,
Anthony PERARD (3):
OvmfPkg: Introduce runtime XenHypercallLib
OvmfPkg/XenHypercallLib: Add SchedOp hypercall
OvmfPkg/OvmfXen: Introduce Xen's ResetSystemLib, to use xen hypercall
OvmfPkg/OvmfXen.dsc | 11 +-
...ystemLib.inf => BaseResetSystemLibXen.inf} | 9 +-
...SystemLib.inf => DxeResetSystemLibXen.inf} | 11 +-
.../XenHypercallRuntimeLib.inf| 46
OvmfPkg/Include/IndustryStandard/Xen/sched.h | 50 +
OvmfPkg/Include/Library/XenHypercallLib.h | 7 +
...ResetShutdown.c => BaseResetShutdownXen.c} | 19 +-
...eResetShutdown.c => DxeResetShutdownXen.c} | 26 ++-
.../XenHypercallLib/X86RuntimeXenHypercall.c | 210 ++
.../Library/XenHypercallLib/XenHypercall.c| 14 ++
.../X64/RuntimeHypercallPage.nasm | 24 ++
11 files changed, 401 insertions(+), 26 deletions(-)
copy OvmfPkg/Library/ResetSystemLib/{BaseResetSystemLib.inf =>
BaseResetSystemLibXen.inf} (73%)
copy OvmfPkg/Library/ResetSystemLib/{DxeResetSystemLib.inf =>
DxeResetSystemLibXen.inf} (73%)
create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallRuntimeLib.inf
create mode 100644 OvmfPkg/Include/IndustryStandard/Xen/sched.h
copy OvmfPkg/Library/ResetSystemLib/{BaseResetShutdown.c =>
BaseResetShutdownXen.c} (72%)
copy OvmfPkg/Library/ResetSystemLib/{DxeResetShutdown.c =>
DxeResetShutdownXen.c} (72%)
create mode 100644 OvmfPkg/Library/XenHypercallLib/X86RuntimeXenHypercall.c
create mode 100644
OvmfPkg/Library/XenHypercallLib/X64/RuntimeHypercallPage.nasm
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96302): https://edk2.groups.io/g/devel/message/96302
Mute This Topic: https://groups.io/mt/94960813/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH] MdePkg/SecPeiDxeTimerLibCpu: Better support for dynamic PcdFSBClock
From: Anthony PERARD
The PcdFSBClock can be a dynamic PCD. This can be an issue when
InternalX86GetTimerFrequency() tries to get the value while been
called with TPL been set to TPL_HIGH_LEVEL.
When the PCD is dynamic, PcdGet*() calls a function that try to grab a
lock which set TPL to TPL_NOTIFY. If TPL is already at TPL_HIGH_LEVEL,
then an assert() in RaiseTPL() fails (in debug build).
To try to avoid the issue, we'll store the current PcdFSBClock value
in a local variable the first time we need it.
The issue was discovered while attempting to boot a Windows guest with
OvmfXen platform. The issue appear while executing the Windows's boot
loader EFI application.
The down side of this change is that when the PCD is FixedAtBuild, the
value is loaded from a variable rather than been a constant.
Signed-off-by: Anthony PERARD
---
InternalX86GetTimerFrequency() is called by
- MicroSecondDelay()
- NanoSecondDelay()
- GetPerformanceCounterProperties()
If one of those functions is called for the first time with a TPL too
high, the work around in this patch would not work. But it seems to
workaround the issue in my test case. So maybe that's enough, unless
someone have a better idea?
---
MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
b/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
index c60589607fde..28ff77ad0c1f 100644
--- a/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
+++ b/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
@@ -90,8 +90,16 @@ InternalX86GetTimerFrequency (
IN UINTN ApicBase
)
{
+ STATIC UINT32 mFSBClock;
+
+ if (mFSBClock == 0) {
+ //
+ // Cache current value of PcdFSBClock in case it's a dynamic PCD.
+ //
+ mFSBClock = PcdGet32 (PcdFSBClock);
+ }
return
-PcdGet32 (PcdFSBClock) /
+mFSBClock /
mTimerLibLocalApicDivisor[MmioBitFieldRead32 (ApicBase + APIC_TDCR, 0, 3)];
}
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96077): https://edk2.groups.io/g/devel/message/96077
Mute This Topic: https://groups.io/mt/94891128/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH] Maintainers.txt: Change Anthony's github id
From: Anthony PERARD Signed-off-by: Anthony PERARD --- Maintainers.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Maintainers.txt b/Maintainers.txt index c641414109ad..c2b30b5dd13b 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -524,7 +524,7 @@ F: OvmfPkg/XenIoPvhDxe/ F: OvmfPkg/XenPlatformPei/ F: OvmfPkg/XenPvBlkDxe/ F: OvmfPkg/XenResetVector/ -R: Anthony Perard [sheep] +R: Anthony Perard [tperard] R: Julien Grall [jgrall] PcAtChipsetPkg -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#93911): https://edk2.groups.io/g/devel/message/93911 Mute This Topic: https://groups.io/mt/93724802/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [Patch 1/3] Maintainers.txt: Remove OvmfPkg/XenTimerDxe reference
On Wed, Jul 20, 2022 at 02:58:26PM -0700, Michael D Kinney wrote: > XenTimerDxe has been removed from the OvmfPkg. Remove > file pattern for XenTimerDxe reviews from Maintainers.txt. > > Cc: Anthony Perard > Cc: Julien Grall > Cc: Andrew Fish > Cc: Leif Lindholm > Signed-off-by: Michael D Kinney Acked-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#91627): https://edk2.groups.io/g/devel/message/91627 Mute This Topic: https://groups.io/mt/92515276/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 1/1] OvmfPkg/XenHypercallLib: Fix naming of AArch64
From: Anthony PERARD
Fix path to follow naming convention of "AArch64", and allow the path
in "Maintainers.txt" to work as expected.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3982
Signed-off-by: Anthony PERARD
---
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Jordan Justen
Cc: Gerd Hoffmann
Cc: Julien Grall
---
OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf | 2 +-
.../Library/XenHypercallLib/{Aarch64 => AArch64}/Hypercall.S| 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename OvmfPkg/Library/XenHypercallLib/{Aarch64 => AArch64}/Hypercall.S (100%)
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
index 32ae73f7aac5..edb77872391c 100644
--- a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
@@ -42,7 +42,7 @@ [Sources.ARM]
Arm/Hypercall.S
[Sources.AARCH64]
- Aarch64/Hypercall.S
+ AArch64/Hypercall.S
[Sources]
XenHypercall.c
diff --git a/OvmfPkg/Library/XenHypercallLib/Aarch64/Hypercall.S
b/OvmfPkg/Library/XenHypercallLib/AArch64/Hypercall.S
similarity index 100%
rename from OvmfPkg/Library/XenHypercallLib/Aarch64/Hypercall.S
rename to OvmfPkg/Library/XenHypercallLib/AArch64/Hypercall.S
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#91579): https://edk2.groups.io/g/devel/message/91579
Mute This Topic: https://groups.io/mt/92504085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 1/1] OvmfPkg/XenPvBlkDxe: Fix memory barrier macro
From: Anthony PERARD
The macro "xen_mb()" needs to be a full memory barrier, that is it
needs to also prevent stores from been reorder after loads which an
x86 CPU can do (as I understand from reading [1]). So this patch makes
use of "mfence" instruction.
Currently, there's a good chance that OvmfXen hang in
XenPvBlockSync(), in an infinite loop, waiting for the last request to
be consumed by the backend. On the other hand, the backend didn't know
there were a new request and don't do anything. This is because there
is two ways the backend look for request, either it's working on one
and use RING_FINAL_CHECK_FOR_REQUESTS(), or it's waiting for an
event/notification. So the frontend (OvmfXen) doesn't need to send
a notification if the backend is already working, checking for needed
notification is done by RING_PUSH_REQUESTS_AND_CHECK_NOTIFY().
That last marco is where order of store vs load is important, the
macro first store the fact that there's a new request, then load the
value of the last event that the backend have done to check if an
asynchronous notification is needed. If those store and load are
reorder, OvmfXen could take the wrong decision of not sending a
notification and both sides just wait.
To fix this, we need to tell the CPU to not reorder stores after loads.
Aarch64 implementation of MemoryFence() is using "dmb sy" which seems
to prevent any reordering.
[1] https://en.wikipedia.org/wiki/Memory_ordering#Runtime_memory_ordering
Signed-off-by: Anthony PERARD
---
I'm not sure what would be the correct implementation on MSFT,
_ReadWriteBarrier() seems to be only a compiler barrier, and I don't
know whether _mm_mfence() is just "mfence" or if it act as a compiler
barrier as well.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Jordan Justen
Cc: Gerd Hoffmann
Cc: Julien Grall
---
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf | 8 ++
OvmfPkg/XenPvBlkDxe/FullMemoryFence.h| 27
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h| 3 ++-
OvmfPkg/XenPvBlkDxe/X86GccFullMemoryFence.c | 20 +++
OvmfPkg/XenPvBlkDxe/X86MsftFullMemoryFence.c | 22
5 files changed, 79 insertions(+), 1 deletion(-)
create mode 100644 OvmfPkg/XenPvBlkDxe/FullMemoryFence.h
create mode 100644 OvmfPkg/XenPvBlkDxe/X86GccFullMemoryFence.c
create mode 100644 OvmfPkg/XenPvBlkDxe/X86MsftFullMemoryFence.c
diff --git a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
index 5dd8e8be1183..dc91865265c1 100644
--- a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+++ b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
@@ -30,9 +30,17 @@ [Sources]
ComponentName.c
ComponentName.h
DriverBinding.h
+ FullMemoryFence.h
XenPvBlkDxe.c
XenPvBlkDxe.h
+[Sources.IA32]
+ X86GccFullMemoryFence.c | GCC
+ X86MsftFullMemoryFence.c | MSFT
+
+[Sources.X64]
+ X86GccFullMemoryFence.c | GCC
+ X86MsftFullMemoryFence.c | MSFT
[LibraryClasses]
UefiDriverEntryPoint
diff --git a/OvmfPkg/XenPvBlkDxe/FullMemoryFence.h
b/OvmfPkg/XenPvBlkDxe/FullMemoryFence.h
new file mode 100644
index ..e3d1df3d0e9d
--- /dev/null
+++ b/OvmfPkg/XenPvBlkDxe/FullMemoryFence.h
@@ -0,0 +1,27 @@
+/** @file
+ Copyright (C) 2022, Citrix Ltd.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#if defined (MDE_CPU_IA32) || defined (MDE_CPU_X64)
+
+//
+// Like MemoryFence() but prevent stores from been reorded with loads by
+// the CPU on X64.
+//
+VOID
+EFIAPI
+FullMemoryFence (
+ VOID
+ );
+
+#else
+
+//
+// Only implement FullMemoryFence() on X86 as MemoryFence() is probably
+// fine on other platform.
+//
+#define FullMemoryFence() MemoryFence()
+
+#endif
diff --git a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
index 350b7bd309c0..67ee1899e9a8 100644
--- a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
+++ b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
@@ -11,8 +11,9 @@
#define __EFI_XEN_PV_BLK_DXE_H__
#include
+#include "FullMemoryFence.h"
-#define xen_mb() MemoryFence()
+#define xen_mb() FullMemoryFence()
#define xen_rmb() MemoryFence()
#define xen_wmb() MemoryFence()
diff --git a/OvmfPkg/XenPvBlkDxe/X86GccFullMemoryFence.c
b/OvmfPkg/XenPvBlkDxe/X86GccFullMemoryFence.c
new file mode 100644
index ..92d107def470
--- /dev/null
+++ b/OvmfPkg/XenPvBlkDxe/X86GccFullMemoryFence.c
@@ -0,0 +1,20 @@
+/** @file
+ Copyright (C) 2022, Citrix Ltd.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include "FullMemoryFence.h"
+
+//
+// Like MemoryFence() but prevent stores from been reorded with loads by
+// the CPU on X64.
+//
+VOID
+EFIAPI
+FullMemoryFence (
+ VOID
+ )
+{
+ __asm__ __volatile__ ("mfence":::"memory");
+}
diff --git a/OvmfPkg/XenPvBlkDxe/X86MsftFullMemoryFence.c
b/OvmfPkg/XenPvBlkDxe/X86MsftFullMemoryFence.c
new file mode 100644
index ..fcb08f7601cd
--- /dev/null
+++ b/OvmfPkg/XenPvBlkDxe/X86MsftFullMemoryFence.c
@@ -0,0 +1,22 @@
+
Re: 回复: [edk2-devel] [PATCH v2 2/7] MdePkg: Allow PcdFSBClock to by Dynamic
On Fri, Jul 08, 2022 at 10:14:35AM +0800, gaoliming wrote:
> Ray:
> The problem is that PcdFSBClock is configured as Dynamic on OVMF.
> Anthony:
> Have you any suggestion for this problem?
>
> Liming
>
> 发件人: devel@edk2.groups.io 代表 ray_l...@hotmail.com
> 发送时间: 2022年7月7日 12:13
> 收件人: Anthony PERARD ; devel@edk2.groups.io
> 主题: Re: [edk2-devel] [PATCH v2 2/7] MdePkg: Allow PcdFSBClock to by Dynamic
>
> On Thu, Mar 25, 2021 at 11:47 PM, Anthony PERARD wrote:
>
> - ## This value is used to configure X86 Processor FSB clock.
> - # @Prompt FSB Clock.
> - gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c
>
> hi, Sir
>
> This change caused the OVMF failed to load in QEMU when compiled with
> "SOURCE_DEBUG_ENABLE" as True.
>
> the verbose message of QEMU shows:
>
> ASSERT [SecMain] d:\myedk2\edk2\MdePkg\Library\BasePcdLibNull\PcdLib.c(95):
> ((BOOLEAN)(0==1))
>
> The failure point is PcdGet32 (PcdFSBClock) of debugtimer.c, I rolled back
> above change, then issue disappeared.
What if you revert c37cbc030d96 ("OvmfPkg: Switch timer in build time
for OvmfPkg") instead? That commit seems to introduce PcdFSBClock as
dynamic in OvmfPkg*.dsc. But revert isn't going to be possible so
instead you could move "PcdFSBClock" to the [PcdsFixedAtBuild] sections
of all "OvmfPkg*.dsc". The dynamic nature of the pcd was only meant to
be used by OvmfXen, and no other platforms.
Cheers,
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#91178): https://edk2.groups.io/g/devel/message/91178
Mute This Topic: https://groups.io/mt/92243726/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH V3 3/3] OvmfPkg: Move LocalApicTimerDxe to UefiCpuPkg
On Mon, Nov 08, 2021 at 02:08:00PM +0800, Min Xu wrote: > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3711 > > OvmfPkg.dec is removed from [Packages] because it doesn't depend > on OvmfPkg. LocalApicTimerDxe is moved to UefiCpuPkg. > > Cc: Jiewen Yao > Cc: Gerd Hoffmann > Cc: Anthony Perard > Cc: Julien Grall > Cc: Eric Dong > Cc: Ray Ni > Signed-off-by: Min Xu Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#83652): https://edk2.groups.io/g/devel/message/83652 Mute This Topic: https://groups.io/mt/86900367/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH V3 1/3] OvmfPkg: Rename XenTimerDxe to LocalApicTimerDxe
On Mon, Nov 08, 2021 at 02:07:58PM +0800, Min Xu wrote: > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3711 > > XenTimerDxe is a local Apic timer driver and it has nothing to do > with Xen. So rename it to LocalApicTimerDxe. > > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: Brijesh Singh > Cc: Erdem Aktas > Cc: James Bottomley > Cc: Jiewen Yao > Cc: Tom Lendacky > Cc: Gerd Hoffmann > Cc: Anthony Perard > Cc: Julien Grall > Signed-off-by: Min Xu Acked-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#83651): https://edk2.groups.io/g/devel/message/83651 Mute This Topic: https://groups.io/mt/86900363/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH] OvmfPkg/OvmfXen: Fix build with QemuKernelLoaderFsDxe
From: Anthony PERARD
VerifyBlob() has been added recently to QemuKernelLoaderFsDxe, also
QemuKernelLoaderFsDxe has also been added recently to OvmfXen but
without an implementation of VerifyBlob().
Fix this by adding the same runes that has been addde to
OvmfPkgX64.dsc.
Fixes: 9f3eda177a4b ("OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxe")
Signed-off-by: Anthony PERARD
---
OvmfPkg/OvmfXen.dsc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 1a9c06c164a8..a31519e356b7 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -587,7 +587,10 @@ [Components]
NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
!endif
}
- OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
+ OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
+
+ NULL|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf
+ }
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80272): https://edk2.groups.io/g/devel/message/80272
Mute This Topic: https://groups.io/mt/85412796/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 1/4] OvmfPkg/OvmfXen: set PcdAcpiS3Enable at initialization
On Mon, Aug 23, 2021 at 03:09:22PM +0800, Gary Lin wrote: > https://bugzilla.tianocore.org/show_bug.cgi?id=3573 > > 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 PcdAcpiS3Enable as > InitializePlatform() did, this made the inconsistency between > drivers/functions. > > For example, S3SaveStateDxe checked PcdAcpiS3Enable and skipped > S3BootScript because the default value is FALSE. On the other hand, > PlatformBootManagerBeforeConsole() from OvmfPkg/Library called > QemuFwCfgS3Enabled() and found it returned TRUE, so it invoked > SaveS3BootScript(). However, S3SaveStateDxe skipped S3BootScript, so > SaveS3BootScript() asserted due to EFI_NOT_FOUND. > > This issue mainly affects "HVM Direct Kernel Boot". When used, > "fw_cfg" is enabled in QEMU and QemuFwCfgS3Enabled() returns true in > that case. > > v3: > - Update the description per Anthony's suggestion > - Add the bugzilla link > v2: > - Amend the description and address "HVM Direct Kernel Boot" > - Add the comment for the conditional test of QemuFwCfgS3Enabled() > - Remove unused QemuFwCfgLib > > Cc: Ard Biesheuvel > Cc: Jiewen Yao > Cc: Jordan Justen > Cc: Anthony Perard > Cc: Julien Grall > Cc: Jim Fehlig > Cc: Joey Li > Signed-off-by: Gary Lin Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#79713): https://edk2.groups.io/g/devel/message/79713 Mute This Topic: https://groups.io/mt/85080301/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 2/5] OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxe
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: You receive all messages sent to this group. View/Reply Online (#79586): https://edk2.groups.io/g/devel/message/79586 Mute This Topic: https://groups.io/mt/84857772/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/5] OvmfPkg/OvmfXen: set PcdAcpiS3Enable at initialization
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 PcdAcpiS3Enable as > InitializePlatform() did, this made the inconsistency between > drivers/functions. > > For example, S3SaveStateDxe checked PcdAcpiS3Enable and skipped > S3BootScript because the default value is FALSE. On the other hand, > PlatformBootManagerBeforeConsole() from OvmfPkg/Library called > QemuFwCfgS3Enabled() and found it returned TRUE, so it invoked > SaveS3BootScript(). However, S3SaveStateDxe skipped S3BootScript, so > SaveS3BootScript() asserted due to EFI_NOT_FOUND. > > This issue mainly affects "HVM Direct Kernel Boot". If "acpi_s3" is > set as "True" in xl.cfg, then the S3 Support bit is set and passed > with fw_cfg. The part about acpi_s3 isn't true, it doesn't affect fw_cfg. Maybe this paragraph would be better: This issue mainly affects "HVM Direct Kernel Boot". When used, "fw_cfg" is enabled in QEMU and QemuFwCfgS3Enabled() returns true in that case. The rest of the patch looks good, thanks. -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#79585): https://edk2.groups.io/g/devel/message/79585 Mute This Topic: https://groups.io/mt/84857773/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [RFC PATCH] OvmfPkg/OvmfXen: set PcdAcpiS3Enable at initialization
On Wed, Jul 21, 2021 at 02:56:46PM +0800, Gary Lin wrote: > BTW, it seems to me that QEMU fwcfg is only used for Xen Direct Kernel > Boot. However, per xl.cfg manpage, it's possible to turn on or off S3 > support by setting "acpi_s3" in xl.cfg, but PcdAcpiS3Enable wasn't set > in the current OvmfXen implementation. Just wonder how xl passes the S3 > support bit to OvmfXen. It doesn't. "acpi_s3" doesn't have any control over PcdAcpiS3Enable, and doesn't have any control over QEMU, so QEMU would probably always say S3 is available. What happen when "acpi_s3" is set or not is: - the value is stored in xenstore - hvmloader (which runs before OVMF) read the xenstore value and adds the appropriate ACPI SSDT table to allow S3. Cheers, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#78209): https://edk2.groups.io/g/devel/message/78209 Mute This Topic: https://groups.io/mt/84061313/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [RFC PATCH] OvmfPkg/OvmfXen: set PcdAcpiS3Enable at initialization
It would have been nice to have this patch in a patch series with
"OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxe", mostly to make it simpler
to understand the problem needed to be fixed.
On Thu, Jul 08, 2021 at 12:05:49PM +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 PcdAcpiS3Enable as
> InitializePlatform() did, this made the inconsistency between
> drivers/functions.
>
> For example, S3SaveStateDxe checked PcdAcpiS3Enable and skipped
> S3BootScript because the default value is FALSE. On the other hand,
> PlatformBootManagerBeforeConsole() from OvmfPkg/Library called
> QemuFwCfgS3Enabled() and found it returned TRUE, so it invoked
> SaveS3BootScript(). However, S3SaveStateDxe skipped S3BootScript, so
> SaveS3BootScript() asserted due to EFI_NOT_FOUND.
This sounds like OvmfPkg would need to be fixed to use PcdAcpiS3Enable
instead of QemuFwCfgS3Enabled() in most placed and have a single place
where QemuFwCfgS3Enabled() is used to set PcdAcpiS3Enable. If you feel
like trying to fix that, that would be nice, and then we could probably
set PcdAcpiS3Enable unconditionally on OvmfXen (and maybe hope that S3
support actually works with Xen).
In the mean time, this patch is fine but wants better comments. First
two paragraphs are good, but the rest needs explanation on what we are
trying to fix/workaround, that is "Direct Kernel Boot" as it is called
in "man xl.cfg".
> Setting PcdAcpiS3Enable at InitializeXenPlatform() "fixes" the crash
> reported by my colleague. The other possible direction is to replace
> QemuFwCfgS3Enabled() with PcdAcpiS3Enable. I'm not sure which one is
> the right fix.
>
> Signed-off-by: Gary Lin
> ---
> diff --git a/OvmfPkg/XenPlatformPei/Platform.c
> b/OvmfPkg/XenPlatformPei/Platform.c
> index a811e72ee301..f7edc979486e 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -26,6 +26,8 @@
> #include
> #include
> #include
> +#include
I don't think QemuFwCfgLib.h is needed, can you remove it?
> +#include
> #include
> #include
> #include
> @@ -433,6 +437,12 @@ InitializeXenPlatform (
> CpuDeadLoop ();
>}
>
> + if (QemuFwCfgS3Enabled ()) {
This test needs a comment. QEMU's fwcfg isn't supposed to be available,
unless one try to use the Direct Kernel Boot functionality.
> +DEBUG ((DEBUG_INFO, "S3 support was detected on QEMU\n"));
> +Status = PcdSetBoolS (PcdAcpiS3Enable, TRUE);
> +ASSERT_EFI_ERROR (Status);
> + }
> +
>XenConnect ();
>
>BootModeInitialization ();
> diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> index 597cb6fcd7ff..1e22c0b2e2aa 100644
> --- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> +++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> @@ -57,6 +57,8 @@ [LibraryClasses]
>ResourcePublicationLib
>PeiServicesLib
>PeimEntryPoint
> + QemuFwCfgLib
Same here, QemuFwCfgLib doesn't seems to be needed or used.
Thanks,
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77907): https://edk2.groups.io/g/devel/message/77907
Mute This Topic: https://groups.io/mt/84061313/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxe
On Fri, Jul 09, 2021 at 11:24:23AM +0800, Gary Lin wrote: > Without QemuKernelLoaderFsDxe, QemuLoadKernelImage() couldn't download > the kernel, initrd, and kernel command line from QEMU's fw_cfg. > > Cc: Ard Biesheuvel > cc: Jordan Justen > Cc: Anthony Perard > Cc: Julien Grall > Cc: Jim Fehlig > Signed-off-by: Gary Lin Acked-by: Anthony PERARD And now I understand what the patch "OvmfPkg/OvmfXen: set PcdAcpiS3Enable at initialization" is about. "HVM Direct Kernel Boot" with OVMF simply doesn't work without that other patch. Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#77904): https://edk2.groups.io/g/devel/message/77904 Mute This Topic: https://groups.io/mt/84084251/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [RFC PATCH] OvmfPkg/OvmfXen: set PcdAcpiS3Enable at initialization
On Thu, Jul 08, 2021 at 12:05:49PM +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 PcdAcpiS3Enable as > InitializePlatform() did, this made the inconsistency between > drivers/functions. > > For example, S3SaveStateDxe checked PcdAcpiS3Enable and skipped > S3BootScript because the default value is FALSE. On the other hand, > PlatformBootManagerBeforeConsole() from OvmfPkg/Library called > QemuFwCfgS3Enabled() and found it returned TRUE, so it invoked > SaveS3BootScript(). However, S3SaveStateDxe skipped S3BootScript, so > SaveS3BootScript() asserted due to EFI_NOT_FOUND. > > Setting PcdAcpiS3Enable at InitializeXenPlatform() "fixes" the crash > reported by my colleague. The other possible direction is to replace > QemuFwCfgS3Enabled() with PcdAcpiS3Enable. I'm not sure which one is > the right fix. QemuFwCfgS3Enabled() should always return false as we don't enable QEMU's fwcfg interface in most case when running a Xen guest. So I don't expect "PcdAcpiS3Enable" to ever been set via this patch. Now, maybe we want to set PcdAcpiS3Enable unconditionally but I don't know if S3 support is going to work as expected with OVMF under Xen, I never look at that. What kind of guest are you trying to fix? When does the crash happen? Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#77889): https://edk2.groups.io/g/devel/message/77889 Mute This Topic: https://groups.io/mt/84061313/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH] OvmfPkg/XenPlatformPei: Relocate shared_info page mapping
From: Anthony PERARD
Unfortunately, Xen isn't ready to deal with mapping at the top of the
physical address space, so we relocate the mapping after the LAPIC
location.
See this thread about the issue with the mapping:
-
https://lore.kernel.org/xen-devel/f8c4151a-6dac-d87c-ef46-eb35ada07...@suse.com/
The PhysicalAddressIdentityMapping() call isn't going to do anything
anymore since everything under 4GB is already mapped, but there is no
need to remove the call.
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenPlatformPei/Xen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index a4e82b356936..9c6641895970 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -569,7 +569,7 @@ CalibrateLapicTimer (
EFI_STATUSStatus;
- SharedInfo = (VOID*)((1ULL << mPhysMemAddressWidth) - EFI_PAGE_SIZE);
+ SharedInfo = (VOID*)((UINTN)PcdGet32 (PcdCpuLocalApicBaseAddress) +
SIZE_1MB);
Status = PhysicalAddressIdentityMapping ((EFI_PHYSICAL_ADDRESS)SharedInfo);
if (EFI_ERROR (Status)) {
DEBUG ((DEBUG_ERROR,
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77183): https://edk2.groups.io/g/devel/message/77183
Mute This Topic: https://groups.io/mt/83844392/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 00/43] OvmfPkg: remove Xen support from OvmfPkg*.dsc, in favor of OvmfXen.dsc
On Wed, Jun 02, 2021 at 10:36:49AM +0200, Laszlo Ersek wrote: > Anthony, Julien, > > (or anyone else subscribed to xen-devel -- CC'd now), > > On 05/26/21 22:14, Laszlo Ersek wrote: > > Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 > > Repo: https://pagure.io/lersek/edk2.git > > Branch: xen_split_bz_2122 > > can you please build the OvmfXen platform on this branch, and check if > there are any regressions? Hi Laszlo, OvmfXen seems to be working fine with that branch applied. Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#76076): https://edk2.groups.io/g/devel/message/76076 Mute This Topic: https://groups.io/mt/83110232/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v3 2/7] MdePkg: Allow PcdFSBClock to by Dynamic
We are going to want to change the value of PcdFSBClock at run time in OvmfXen, so move it to the PcdsDynamic section. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 Signed-off-by: Anthony PERARD Reviewed-by: Laszlo Ersek Reviewed-by: Liming Gao --- Notes: CC: Michael D Kinney CC: Liming Gao CC: Zhiguang Liu MdePkg/MdePkg.dec | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index f4156920e599..8965e903e093 100644 --- a/MdePkg/MdePkg.dec +++ b/MdePkg/MdePkg.dec @@ -2265,10 +2265,6 @@ [PcdsFixedAtBuild,PcdsPatchableInModule] # @ValidList 0x8001 | 8, 16, 32 gEfiMdePkgTokenSpaceGuid.PcdPort80DataWidth|8|UINT8|0x002d - ## This value is used to configure X86 Processor FSB clock. - # @Prompt FSB Clock. - gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c - ## The maximum printable number of characters. UefLib functions: AsciiPrint(), AsciiErrorPrint(), # PrintXY(), AsciiPrintXY(), Print(), ErrorPrint() base on this PCD value to print characters. # @Prompt Maximum Printable Number of Characters. @@ -2372,5 +2368,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] # @Prompt Boot Timeout (s) gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0x|UINT16|0x002c + ## This value is used to configure X86 Processor FSB clock. + # @Prompt FSB Clock. + gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c + [UserExtensions.TianoCore."ExtraFiles"] MdePkgExtra.uni -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#73954): https://edk2.groups.io/g/devel/message/73954 Mute This Topic: https://groups.io/mt/82037830/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v3 0/7] OvmfXen: Set PcdFSBClock at runtime
Patch series available in this git branch:
git://xenbits.xen.org/people/aperard/ovmf.git br.apic-timer-freq-v3
Changes in v3:
- typos and codying style
Changes in v2:
- main change is to allow mapping of Xen pages outside of the RAM
see patch: "OvmfPkg/XenPlatformPei: Map extra physical address"
- that new function allows to map the Xen shared info page (where we can find
information about tsc frequency) at the highest physical address allowed.
Hi,
OvmfXen uses the APIC timer, but with an hard-coded frequency that may change
as pointed out here:
https://edk2.groups.io/g/devel/message/45185
<20190808134423.ybqg3qkpw5ucfzk4@Air-de-Roger>
This series changes that so the frequency is calculated at runtime.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
There is also one cleanup patch that has nothing to do with the rest.
Cheers,
Anthony PERARD (7):
OvmfPkg/XenResetVector: Silent a warning from nasm
MdePkg: Allow PcdFSBClock to by Dynamic
OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to
XEN_VCPU_TIME_INFO
OvmfPkg/IndustryStandard: Introduce PageTable.h
OvmfPkg/XenPlatformPei: Map extra physical address
OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency
OvmfPkg/OvmfXen: Set PcdFSBClock
MdePkg/MdePkg.dec | 8 +-
OvmfPkg/OvmfXen.dsc | 4 +-
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 4 +
.../IndustryStandard/PageTable.h} | 117 +---
OvmfPkg/Include/IndustryStandard/Xen/xen.h| 17 +-
.../BaseMemEncryptSevLib/X64/VirtualMemory.h | 143 +-
OvmfPkg/XenPlatformPei/Platform.h | 10 +
OvmfPkg/XenPlatformPei/Platform.c | 1 +
OvmfPkg/XenPlatformPei/Xen.c | 252 ++
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm| 2 +-
10 files changed, 287 insertions(+), 271 deletions(-)
copy OvmfPkg/{Library/BaseMemEncryptSevLib/X64/VirtualMemory.h =>
Include/IndustryStandard/PageTable.h} (60%)
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73952): https://edk2.groups.io/g/devel/message/73952
Mute This Topic: https://groups.io/mt/82037827/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v3 5/7] OvmfPkg/XenPlatformPei: Map extra physical address
Some information available in a Xen guest can be mapped anywhere in
the physical address space and they don't need to be backed by RAM.
For example, the shared info page.
While it's easier to put those pages anywhere, it is better to avoid
mapping it where the RAM is. It might split a nice 1G guest page table
into 4k pages and thus reducing performance of the guest when it
accesses its memory. Also mapping a page like the shared info page and
then unmapping it or mapping it somewhere else would leave a hole in
the RAM that the guest would propably not be able to use anymore.
So the patch introduces a new function which can be used to 1:1
mapping of guest physical memory above 4G during the PEI phase so we
can map the Xen shared pages outside of memory that can be used by
guest, and as high as possible.
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v3:
- fix typos
v2:
- new patch
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
OvmfPkg/XenPlatformPei/Platform.h | 5 ++
OvmfPkg/XenPlatformPei/Xen.c | 71 +++
3 files changed, 77 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 0ef77db92c03..8790d907d3ec 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -66,6 +66,7 @@ [Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
b/OvmfPkg/XenPlatformPei/Platform.h
index 7661f4a8de0a..e70ca58078eb 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -127,6 +127,11 @@ XenGetE820Map (
UINT32 *Count
);
+EFI_STATUS
+PhysicalAddressIdentityMapping (
+ IN EFI_PHYSICAL_ADDRESS AddressToMap
+ );
+
extern EFI_BOOT_MODE mBootMode;
extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index c41fecdc486e..b2a7d1c21dac 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -17,6 +17,8 @@
//
// The Library classes this module consumes
//
+#include
+#include
#include
#include
#include
@@ -25,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -386,3 +389,71 @@ InitializeXen (
return EFI_SUCCESS;
}
+
+EFI_STATUS
+PhysicalAddressIdentityMapping (
+ IN EFI_PHYSICAL_ADDRESS AddressToMap
+ )
+{
+ INTNIndex;
+ PAGE_MAP_AND_DIRECTORY_POINTER *L4, *L3;
+ PAGE_TABLE_ENTRY*PageTable;
+
+ DEBUG ((DEBUG_INFO, "Mapping 1:1 of address 0x%lx\n", (UINT64)AddressToMap));
+
+ // L4 / Top level Page Directory Pointers
+
+ L4 = (VOID*)(UINTN)PcdGet32 (PcdOvmfSecPageTablesBase);
+ Index = PML4_OFFSET (AddressToMap);
+
+ if (!L4[Index].Bits.Present) {
+L3 = AllocatePages (1);
+if (L3 == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+}
+
+ZeroMem (L3, EFI_PAGE_SIZE);
+
+L4[Index].Bits.ReadWrite = 1;
+L4[Index].Bits.Accessed = 1;
+L4[Index].Bits.PageTableBaseAddress = (EFI_PHYSICAL_ADDRESS)L3 >> 12;
+L4[Index].Bits.Present = 1;
+ }
+
+ // L3 / Next level Page Directory Pointers
+
+ L3 = (VOID*)(EFI_PHYSICAL_ADDRESS)(L4[Index].Bits.PageTableBaseAddress <<
12);
+ Index = PDP_OFFSET (AddressToMap);
+
+ if (!L3[Index].Bits.Present) {
+PageTable = AllocatePages (1);
+if (PageTable == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+}
+
+ZeroMem (PageTable, EFI_PAGE_SIZE);
+
+L3[Index].Bits.ReadWrite = 1;
+L3[Index].Bits.Accessed = 1;
+L3[Index].Bits.PageTableBaseAddress = (EFI_PHYSICAL_ADDRESS)PageTable >>
12;
+L3[Index].Bits.Present = 1;
+ }
+
+ // L2 / Page Table Entries
+
+ PageTable =
(VOID*)(EFI_PHYSICAL_ADDRESS)(L3[Index].Bits.PageTableBaseAddress << 12);
+ Index = PDE_OFFSET (AddressToMap);
+
+ if (!PageTable[Index].Bits.Present) {
+PageTable[Index].Bits.ReadWrite = 1;
+PageTable[Index].Bits.Accessed = 1;
+PageTable[Index].Bits.Dirty = 1;
+PageTable[Index].Bits.MustBe1 = 1;
+PageTable[Index].Bits.PageTableBaseAddress = AddressToMap >> 21;
+PageTable[Index].Bits.Present = 1;
+ }
+
+ CpuFlushTlb ();
+
+ return EFI_SUCCESS;
+}
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73958): https://edk2.groups.io/g/devel/message/73958
Mute This Topic: https://groups.io/mt/82037839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v3 7/7] OvmfPkg/OvmfXen: Set PcdFSBClock
Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct
value when SecPeiDxeTimerLibCpu start to use it for the APIC timer.
Currently, nothing appear to use the value in PcdFSBClock before
XenPlatformPei had a chance to set it even though TimerLib is included
in modules run before XenPlatformPei.
XenPlatformPei doesn't use any of the functions that would use that
value. No other modules in the PEI phase seems to use the TimerLib
before PcdFSBClock is set. There are currently two other modules in
the PEI phase that needs the TimerLib:
- S3Resume2Pei, but only because LocalApicLib needs it, but nothing is
using the value from PcdFSBClock.
- CpuMpPei, but I believe it only runs after XenPlatformPei
Before the PEI phase, there's the SEC phase, and SecMain needs
TimerLib because of LocalApicLib. And it initialise the APIC timers
for the debug agent. But I don't think any of the DebugLib that
OvmfXen could use are actually using the *Delay functions in TimerLib,
and so would not use the value from PcdFSBClock which would be
uninitialised.
A simple runtime test showed that TimerLib doesn't use PcdFSBClock
value before it is set.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v3:
- cast Freq in assert
- fix typos
- use correct assert to check Status
v2:
- keep the default value of PcdFSBClock because that is part of the syntax.
OvmfPkg/OvmfXen.dsc | 4 +---
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
OvmfPkg/XenPlatformPei/Xen.c | 4
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 86abe277c349..e535503e385d 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -447,9 +447,6 @@ [PcdsFixedAtBuild]
# Point to the MdeModulePkg/Application/UiApp/UiApp.inf
gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c,
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
- ## Xen vlapic's frequence is 100 MHz
- gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
-
# We populate DXE IPL tables with 1G pages preferably on Xen
gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable|TRUE
@@ -476,6 +473,7 @@ [PcdsDynamicDefault]
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x8
+ gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
# Set video resolution for text setup.
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 5732d2188871..87dd4b24679a 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -85,6 +85,7 @@ [Pcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
+ gEfiMdePkgTokenSpaceGuid.PcdFSBClock
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 8b06bebd7731..2dc9f9ff8f3c 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -632,5 +632,9 @@ CalibrateLapicTimer (
Freq = DivU64x64Remainder (Dividend, TscTick2 - TscTick, NULL);
DEBUG ((DEBUG_INFO, "APIC Freq % 8lu Hz\n", Freq));
+ ASSERT ((UINT32)Freq <= MAX_UINT32);
+ Status = PcdSet32S (PcdFSBClock, Freq);
+ ASSERT_EFI_ERROR (Status);
+
UnmapXenPage (SharedInfo);
}
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73957): https://edk2.groups.io/g/devel/message/73957
Mute This Topic: https://groups.io/mt/82037835/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v3 6/7] OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency
Calculate the frequency of the APIC timer that Xen provides.
Even though the frequency is currently hard-coded, it isn't part of
the public ABI that Xen provides and thus may change at any time. OVMF
needs to determine the frequency by an other mean.
Fortunately, Xen provides a way to determines the frequency of the
TSC, so we can use TSC to calibrate the frequency of the APIC timer.
That information is found in the shared_info page which we map and
unmap once done (XenBusDxe is going to map the page somewhere else).
The shared_info page is mapped at the highest physical address allowed
as it doesn't need to be in the RAM, thus there's a call to update the
page table.
The calculated frequency is only logged in this patch, it will be used
in a following patch.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
CC: Roger Pau Monné
v3:
- fix debug format strings
- fix coding style
v2:
- fix CamelCases
- Use U64 multiplication and division helpers
- don't read TscShift from the SharedInfo page again
- change the location of the shared info page to be outside of the ram
- check for overflow in XenDelay
- check for overflow when calculating the calculating APIC frequency
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 2 +
OvmfPkg/XenPlatformPei/Platform.h | 5 +
OvmfPkg/XenPlatformPei/Platform.c | 1 +
OvmfPkg/XenPlatformPei/Xen.c | 177 ++
4 files changed, 185 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 8790d907d3ec..5732d2188871 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -52,6 +52,7 @@ [LibraryClasses]
DebugLib
HobLib
IoLib
+ LocalApicLib
PciLib
ResourcePublicationLib
PeiServicesLib
@@ -59,6 +60,7 @@ [LibraryClasses]
MtrrLib
MemEncryptSevLib
PcdLib
+ SafeIntLib
XenHypercallLib
[Pcd]
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
b/OvmfPkg/XenPlatformPei/Platform.h
index e70ca58078eb..77d88fc159d7 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -132,6 +132,11 @@ PhysicalAddressIdentityMapping (
IN EFI_PHYSICAL_ADDRESS AddressToMap
);
+VOID
+CalibrateLapicTimer (
+ VOID
+ );
+
extern EFI_BOOT_MODE mBootMode;
extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/Platform.c
b/OvmfPkg/XenPlatformPei/Platform.c
index 717fd0ab1a45..e9511eb40c62 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -448,6 +448,7 @@ InitializeXenPlatform (
InitializeRamRegions ();
InitializeXen ();
+ CalibrateLapicTimer ();
if (mBootMode != BOOT_ON_S3_RESUME) {
ReserveEmuVariableNvStore ();
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index b2a7d1c21dac..8b06bebd7731 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -21,8 +21,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -457,3 +459,178 @@ PhysicalAddressIdentityMapping (
return EFI_SUCCESS;
}
+
+STATIC
+EFI_STATUS
+MapSharedInfoPage (
+ IN VOID *PagePtr
+ )
+{
+ xen_add_to_physmap_t Parameters;
+ INTN ReturnCode;
+
+ Parameters.domid = DOMID_SELF;
+ Parameters.space = XENMAPSPACE_shared_info;
+ Parameters.idx = 0;
+ Parameters.gpfn = (UINTN)PagePtr >> EFI_PAGE_SHIFT;
+ ReturnCode = XenHypercallMemoryOp (XENMEM_add_to_physmap, );
+ if (ReturnCode != 0) {
+return EFI_NO_MAPPING;
+ }
+ return EFI_SUCCESS;
+}
+
+STATIC
+VOID
+UnmapXenPage (
+ IN VOID *PagePtr
+ )
+{
+ xen_remove_from_physmap_t Parameters;
+ INTN ReturnCode;
+
+ Parameters.domid = DOMID_SELF;
+ Parameters.gpfn = (UINTN)PagePtr >> EFI_PAGE_SHIFT;
+ ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap, );
+ ASSERT (ReturnCode == 0);
+}
+
+
+STATIC
+UINT64
+GetCpuFreq (
+ IN XEN_VCPU_TIME_INFO *VcpuTime
+ )
+{
+ UINT32 Version;
+ UINT32 TscToSystemMultiplier;
+ INT8 TscShift;
+ UINT64 CpuFreq;
+
+ do {
+Version = VcpuTime->Version;
+MemoryFence ();
+TscToSystemMultiplier = VcpuTime->TscToSystemMultiplier;
+TscShift = VcpuTime->TscShift;
+MemoryFence ();
+ } while (((Version & 1) != 0) && (Version != VcpuTime->Version));
+
+ CpuFreq = DivU64x32 (LShiftU64 (10ULL, 32), TscToSystemMultiplier);
+ if (TscShift >= 0) {
+ CpuFreq = RShiftU64 (CpuFreq, TscShift);
+ } else {
+ CpuFreq = LShiftU64 (CpuFreq, -TscShift);
+ }
+ return CpuFreq;
+}
+
+STATIC
+VOID
+XenDelay (
+ IN XEN_VCPU_TIME_INFO *VcpuTimeInfo,
+ IN UINT64 DelayNs
+ )
+{
+ UINT64Tick;
+ UINT64CpuFreq;
+ UINT64Delay;
+ UINT64DelayTick;
+
[edk2-devel] [PATCH v3 3/7] OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to XEN_VCPU_TIME_INFO
We are going to use new fields from the Xen headers. Apply the EDK2
coding style so that the code that is going to use it doesn't look out
of place.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v2:
- fix case of Tsc* field
OvmfPkg/Include/IndustryStandard/Xen/xen.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/xen.h
b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
index e55d93263285..79a4e212e7c2 100644
--- a/OvmfPkg/Include/IndustryStandard/Xen/xen.h
+++ b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
@@ -183,10 +183,10 @@ struct vcpu_time_info {
* The correct way to interact with the version number is similar to
* Linux's seqlock: see the implementations of read_seqbegin/read_seqretry.
*/
-UINT32 version;
+UINT32 Version;
UINT32 pad0;
-UINT64 tsc_timestamp; /* TSC at last update of time vals. */
-UINT64 system_time; /* Time, in nanosecs, since boot.*/
+UINT64 TscTimestamp; /* TSC at last update of time vals. */
+UINT64 SystemTime; /* Time, in nanosecs, since boot.*/
/*
* Current system time:
* system_time +
@@ -194,11 +194,11 @@ struct vcpu_time_info {
* CPU frequency (Hz):
* ((10^9 << 32) / tsc_to_system_mul) >> tsc_shift
*/
-UINT32 tsc_to_system_mul;
-INT8 tsc_shift;
+UINT32 TscToSystemMultiplier;
+INT8 TscShift;
INT8 pad1[3];
}; /* 32 bytes */
-typedef struct vcpu_time_info vcpu_time_info_t;
+typedef struct vcpu_time_info XEN_VCPU_TIME_INFO;
struct vcpu_info {
/*
@@ -234,7 +234,7 @@ struct vcpu_info {
#endif /* XEN_HAVE_PV_UPCALL_MASK */
xen_ulong_t evtchn_pending_sel;
struct arch_vcpu_info arch;
-struct vcpu_time_info time;
+struct vcpu_time_info Time;
}; /* 64 bytes (x86) */
#ifndef __XEN__
typedef struct vcpu_info vcpu_info_t;
@@ -250,7 +250,7 @@ typedef struct vcpu_info vcpu_info_t;
* of this structure remaining constant.
*/
struct shared_info {
-struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS];
+struct vcpu_info VcpuInfo[XEN_LEGACY_MAX_VCPUS];
/*
* A domain can create "event channels" on which it can send and receive
@@ -299,6 +299,7 @@ struct shared_info {
};
#ifndef __XEN__
typedef struct shared_info shared_info_t;
+typedef struct shared_info XEN_SHARED_INFO;
#endif
/* Turn a plain number into a C UINTN constant. */
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73955): https://edk2.groups.io/g/devel/message/73955
Mute This Topic: https://groups.io/mt/82037831/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v3 1/7] OvmfPkg/XenResetVector: Silent a warning from nasm
To avoid nasm generating a warning, replace the macro by the value expected to be stored in eax. Ia32/XenPVHMain.asm:76: warning: dword data exceeds bounds Reported-by: Laszlo Ersek Signed-off-by: Anthony PERARD Reviewed-by: Laszlo Ersek --- OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm index 2df0f12e18cb..c761e9d30729 100644 --- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm @@ -73,7 +73,7 @@ xenPVHMain: ; ; parameter for Flat32SearchForBfvBase ; -mov eax, ADDR_OF(fourGigabytes) +mov eax, 0 ; ADDR_OF(fourGigabytes) add eax, edx ; add delta ; -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#73953): https://edk2.groups.io/g/devel/message/73953 Mute This Topic: https://groups.io/mt/82037828/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v3 4/7] OvmfPkg/IndustryStandard: Introduce PageTable.h
We are going to use the page table structure in yet another place,
collect the types and macro that can be used from another module
rather than making yet another copy.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
Acked-by: Tom Lendacky
---
Notes:
CC: Brijesh Singh
v3:
- fix typos and coding style
v2:
- new patch
.../IndustryStandard/PageTable.h} | 117 +-
.../BaseMemEncryptSevLib/X64/VirtualMemory.h | 143 +-
2 files changed, 5 insertions(+), 255 deletions(-)
copy OvmfPkg/{Library/BaseMemEncryptSevLib/X64/VirtualMemory.h =>
Include/IndustryStandard/PageTable.h} (60%)
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h
b/OvmfPkg/Include/IndustryStandard/PageTable.h
similarity index 60%
copy from OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h
copy to OvmfPkg/Include/IndustryStandard/PageTable.h
index 996f94f07ebb..5e797eeea8ef 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h
+++ b/OvmfPkg/Include/IndustryStandard/PageTable.h
@@ -1,6 +1,6 @@
/** @file
- Virtual Memory Management Services to set or clear the memory encryption bit
+ x86_64 Page Tables structures
Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
Copyright (c) 2017 - 2020, AMD Incorporated. All rights reserved.
@@ -11,17 +11,10 @@
**/
-#ifndef __VIRTUAL_MEMORY__
-#define __VIRTUAL_MEMORY__
+#ifndef PAGE_TABLE_H_
+#define PAGE_TABLE_H_
-#include
-#include
-#include
-#include
-#include
-#include
-
-#define SYS_CODE64_SEL 0x38
+#include
#pragma pack(1)
@@ -165,106 +158,4 @@ typedef union {
#define PTE_OFFSET(x) ( (x >> 12) & PAGETABLE_ENTRY_MASK)
#define PAGING_1G_ADDRESS_MASK_64 0x000FC000ull
-#define PAGE_TABLE_POOL_ALIGNMENT BASE_2MB
-#define PAGE_TABLE_POOL_UNIT_SIZE SIZE_2MB
-#define PAGE_TABLE_POOL_UNIT_PAGES \
- EFI_SIZE_TO_PAGES (PAGE_TABLE_POOL_UNIT_SIZE)
-#define PAGE_TABLE_POOL_ALIGN_MASK \
- (~(EFI_PHYSICAL_ADDRESS)(PAGE_TABLE_POOL_ALIGNMENT - 1))
-
-typedef struct {
- VOID*NextPool;
- UINTN Offset;
- UINTN FreePages;
-} PAGE_TABLE_POOL;
-
-/**
- Return the pagetable memory encryption mask.
-
- @return The pagetable memory encryption mask.
-
-**/
-UINT64
-EFIAPI
-InternalGetMemEncryptionAddressMask (
- VOID
- );
-
-/**
- This function clears memory encryption bit for the memory region specified by
- PhysicalAddress and Length from the current page table context.
-
- @param[in] Cr3BaseAddress Cr3 Base Address (if zero then use
- current CR3)
- @param[in] PhysicalAddress The physical address that is the start
- address of a memory region.
- @param[in] Length The length of memory region
- @param[in] Flush Flush the caches before applying the
- encryption mask
-
- @retval RETURN_SUCCESS The attributes were cleared for the
- memory region.
- @retval RETURN_INVALID_PARAMETERNumber of pages is zero.
- @retval RETURN_UNSUPPORTED Clearing the memory encyrption attribute
- is not supported
-**/
-RETURN_STATUS
-EFIAPI
-InternalMemEncryptSevSetMemoryDecrypted (
- IN PHYSICAL_ADDRESSCr3BaseAddress,
- IN PHYSICAL_ADDRESSPhysicalAddress,
- IN UINTN Length,
- IN BOOLEAN Flush
- );
-
-/**
- This function sets memory encryption bit for the memory region specified by
- PhysicalAddress and Length from the current page table context.
-
- @param[in] Cr3BaseAddress Cr3 Base Address (if zero then use
- current CR3)
- @param[in] PhysicalAddress The physical address that is the start
- address of a memory region.
- @param[in] Length The length of memory region
- @param[in] Flush Flush the caches before applying the
- encryption mask
-
- @retval RETURN_SUCCESS The attributes were set for the memory
- region.
- @retval RETURN_INVALID_PARAMETERNumber of pages is zero.
- @retval RETURN_UNSUPPORTED Setting the memory encyrption attribute
- is not supported
-**/
-RETURN_STATUS
-EFIAPI
-InternalMemEncryptSevSetMemoryEncrypted (
- IN PHYSICAL_ADDRESSCr3BaseAddress,
- IN PHYSICAL_ADDRESSPhysicalAddress,
- IN UINTN Length,
- IN BOOLEAN Flush
- );
-
-/**
- Returns the encryption state of the specified virtual address range.
-
- @param[in] Cr3BaseAddress Cr3 Base Address (if
[edk2-devel] [PATCH v2 5/7] OvmfPkg/XenPlatformPei: Map extra physical address
Some information available in a Xen guest can be mapped anywhere in
the physical address space and they don't need to be backed by RAM.
For example, the shared info page.
While it's easier to put those pages anywhere, it is better to avoid
mapping it where the RAM is. It might split a nice 1G guest page table
into 4k pages and thus reducing performance of the guest when it
access its memory. Also mapping a page like the shared info page and
then unmapping it or mapping it somewhere else would live a hole in
the RAM that the guest would propably not been able to use anymore.
So the patch introduce a new function which can be used to 1:1
mapping of guest physical memory above 4G during the PEI phase so we
can map the Xen shared pages outside of memory that can be used by
guest, and as high as possible.
Signed-off-by: Anthony PERARD
---
Notes:
v2:
- new patch
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
OvmfPkg/XenPlatformPei/Platform.h | 5 ++
OvmfPkg/XenPlatformPei/Xen.c | 71 +++
3 files changed, 77 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 0ef77db92c03..8790d907d3ec 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -66,6 +66,7 @@ [Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
b/OvmfPkg/XenPlatformPei/Platform.h
index 7661f4a8de0a..e70ca58078eb 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -127,6 +127,11 @@ XenGetE820Map (
UINT32 *Count
);
+EFI_STATUS
+PhysicalAddressIdentityMapping (
+ IN EFI_PHYSICAL_ADDRESS AddressToMap
+ );
+
extern EFI_BOOT_MODE mBootMode;
extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index c41fecdc486e..b2a7d1c21dac 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -17,6 +17,8 @@
//
// The Library classes this module consumes
//
+#include
+#include
#include
#include
#include
@@ -25,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -386,3 +389,71 @@ InitializeXen (
return EFI_SUCCESS;
}
+
+EFI_STATUS
+PhysicalAddressIdentityMapping (
+ IN EFI_PHYSICAL_ADDRESS AddressToMap
+ )
+{
+ INTNIndex;
+ PAGE_MAP_AND_DIRECTORY_POINTER *L4, *L3;
+ PAGE_TABLE_ENTRY*PageTable;
+
+ DEBUG ((DEBUG_INFO, "Mapping 1:1 of address 0x%lx\n", (UINT64)AddressToMap));
+
+ // L4 / Top level Page Directory Pointers
+
+ L4 = (VOID*)(UINTN)PcdGet32 (PcdOvmfSecPageTablesBase);
+ Index = PML4_OFFSET (AddressToMap);
+
+ if (!L4[Index].Bits.Present) {
+L3 = AllocatePages (1);
+if (L3 == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+}
+
+ZeroMem (L3, EFI_PAGE_SIZE);
+
+L4[Index].Bits.ReadWrite = 1;
+L4[Index].Bits.Accessed = 1;
+L4[Index].Bits.PageTableBaseAddress = (EFI_PHYSICAL_ADDRESS)L3 >> 12;
+L4[Index].Bits.Present = 1;
+ }
+
+ // L3 / Next level Page Directory Pointers
+
+ L3 = (VOID*)(EFI_PHYSICAL_ADDRESS)(L4[Index].Bits.PageTableBaseAddress <<
12);
+ Index = PDP_OFFSET (AddressToMap);
+
+ if (!L3[Index].Bits.Present) {
+PageTable = AllocatePages (1);
+if (PageTable == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+}
+
+ZeroMem (PageTable, EFI_PAGE_SIZE);
+
+L3[Index].Bits.ReadWrite = 1;
+L3[Index].Bits.Accessed = 1;
+L3[Index].Bits.PageTableBaseAddress = (EFI_PHYSICAL_ADDRESS)PageTable >>
12;
+L3[Index].Bits.Present = 1;
+ }
+
+ // L2 / Page Table Entries
+
+ PageTable =
(VOID*)(EFI_PHYSICAL_ADDRESS)(L3[Index].Bits.PageTableBaseAddress << 12);
+ Index = PDE_OFFSET (AddressToMap);
+
+ if (!PageTable[Index].Bits.Present) {
+PageTable[Index].Bits.ReadWrite = 1;
+PageTable[Index].Bits.Accessed = 1;
+PageTable[Index].Bits.Dirty = 1;
+PageTable[Index].Bits.MustBe1 = 1;
+PageTable[Index].Bits.PageTableBaseAddress = AddressToMap >> 21;
+PageTable[Index].Bits.Present = 1;
+ }
+
+ CpuFlushTlb ();
+
+ return EFI_SUCCESS;
+}
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73275): https://edk2.groups.io/g/devel/message/73275
Mute This Topic: https://groups.io/mt/81605803/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v2 6/7] OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency
Calculate the frequency of the APIC timer that Xen provides.
Even though the frequency is currently hard-coded, it isn't part of
the public ABI that Xen provides and thus may change at any time. OVMF
needs to determine the frequency by an other mean.
Fortunately, Xen provides a way to determines the frequency of the
TSC, so we can use TSC to calibrate the frequency of the APIC timer.
That information is found in the shared_info page which we map and
unmap once done (XenBusDxe is going to map the page somewhere else).
The shared_info page is map at the highest physical address allowed as
it doesn't need to be in the RAM, thus there's a call to update the
page table.
The calculated frequency is only logged in this patch, it will be used
in a following patch.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
---
CC: Roger Pau Monné
---
Notes:
v2:
- fix CamelCases
- Use U64 multiplication and division helpers
- don't read TscShift from the SharedInfo page again
- change the location of the shared info page to be outside of the ram
- check for overflow in XenDelay
- check for overflow when calculating the calculating APIC frequency
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 2 +
OvmfPkg/XenPlatformPei/Platform.h | 5 +
OvmfPkg/XenPlatformPei/Platform.c | 1 +
OvmfPkg/XenPlatformPei/Xen.c | 177 ++
4 files changed, 185 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 8790d907d3ec..5732d2188871 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -52,6 +52,7 @@ [LibraryClasses]
DebugLib
HobLib
IoLib
+ LocalApicLib
PciLib
ResourcePublicationLib
PeiServicesLib
@@ -59,6 +60,7 @@ [LibraryClasses]
MtrrLib
MemEncryptSevLib
PcdLib
+ SafeIntLib
XenHypercallLib
[Pcd]
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
b/OvmfPkg/XenPlatformPei/Platform.h
index e70ca58078eb..77d88fc159d7 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -132,6 +132,11 @@ PhysicalAddressIdentityMapping (
IN EFI_PHYSICAL_ADDRESS AddressToMap
);
+VOID
+CalibrateLapicTimer (
+ VOID
+ );
+
extern EFI_BOOT_MODE mBootMode;
extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/Platform.c
b/OvmfPkg/XenPlatformPei/Platform.c
index 717fd0ab1a45..e9511eb40c62 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -448,6 +448,7 @@ InitializeXenPlatform (
InitializeRamRegions ();
InitializeXen ();
+ CalibrateLapicTimer ();
if (mBootMode != BOOT_ON_S3_RESUME) {
ReserveEmuVariableNvStore ();
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index b2a7d1c21dac..7524aaa11a29 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -21,8 +21,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -457,3 +459,178 @@ PhysicalAddressIdentityMapping (
return EFI_SUCCESS;
}
+
+STATIC
+EFI_STATUS
+MapSharedInfoPage (
+ IN VOID *PagePtr
+ )
+{
+ xen_add_to_physmap_t Parameters;
+ INTN ReturnCode;
+
+ Parameters.domid = DOMID_SELF;
+ Parameters.space = XENMAPSPACE_shared_info;
+ Parameters.idx = 0;
+ Parameters.gpfn = (UINTN)PagePtr >> EFI_PAGE_SHIFT;
+ ReturnCode = XenHypercallMemoryOp (XENMEM_add_to_physmap, );
+ if (ReturnCode != 0) {
+return EFI_NO_MAPPING;
+ }
+ return EFI_SUCCESS;
+}
+
+STATIC
+VOID
+UnmapXenPage (
+ IN VOID *PagePtr
+ )
+{
+ xen_remove_from_physmap_t Parameters;
+ INTN ReturnCode;
+
+ Parameters.domid = DOMID_SELF;
+ Parameters.gpfn = (UINTN)PagePtr >> EFI_PAGE_SHIFT;
+ ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap, );
+ ASSERT (ReturnCode == 0);
+}
+
+
+STATIC
+UINT64
+GetCpuFreq (
+ IN XEN_VCPU_TIME_INFO *VcpuTime
+ )
+{
+ UINT32 Version;
+ UINT32 TscToSystemMultiplier;
+ INT8 TscShift;
+ UINT64 CpuFreq;
+
+ do {
+Version = VcpuTime->Version;
+MemoryFence ();
+TscToSystemMultiplier = VcpuTime->TscToSystemMultiplier;
+TscShift = VcpuTime->TscShift;
+MemoryFence ();
+ } while (((Version & 1) != 0) && (Version != VcpuTime->Version));
+
+ CpuFreq = DivU64x32 (LShiftU64 (10ULL, 32), TscToSystemMultiplier);
+ if (TscShift >= 0) {
+ CpuFreq = RShiftU64 (CpuFreq, TscShift);
+ } else {
+ CpuFreq = LShiftU64 (CpuFreq, -TscShift);
+ }
+ return CpuFreq;
+}
+
+STATIC
+VOID
+XenDelay (
+ IN XEN_VCPU_TIME_INFO *VcpuTimeInfo,
+ IN UINT64 DelayNs
+ )
+{
+ UINT64Tick;
+ UINT64CpuFreq;
+ UINT64Delay;
+ UINT64DelayTick;
+ UINT64NewTick;
+ RETURN_STATUS Status;
+
+ Tick = AsmReadTsc ();
+
+ CpuFreq
[edk2-devel] [PATCH v2 7/7] OvmfPkg/OvmfXen: Set PcdFSBClock
Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct
value when SecPeiDxeTimerLibCpu start to use it for the APIC timer.
Currently, nothing appear to use the value in PcdFSBClock before
XenPlatformPei had a chance to set it even though TimerLib is included
in modules runned before XenPlatformPei.
XenPlatformPei doesn't use any of the functions that would use that
value. No other modules in the PEI phase seems to use the TimerLib
before PcdFSBClock is set. There are currently two other modules in
the PEI phase that needs the TimerLib:
- S3Resume2Pei, but only because LocalApicLib needs it, but nothing is
using the value from PcdFSBClock.
- CpuMpPei, but I believe it only runs after XenPlatformPei
Before the PEI phase, there's the SEC phase, and SecMain needs
TimerLib because of LocalApicLib. And it initialise the APIC timers
for the debug agent. But I don't think any of the DebugLib that
OvmfXen could use are actually using the *Delay functions in TimerLib,
and so would not use the value from PcdFSBClock which would be
uninitialised.
A simple runtime test showed that TimerLib doesn't use PcdFSBClock
value before it is set.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v2:
- keep the default value of PcdFSBClock because that is part of the syntax.
OvmfPkg/OvmfXen.dsc | 4 +---
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
OvmfPkg/XenPlatformPei/Xen.c | 4
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 507029404f0b..faf3930ace04 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -442,9 +442,6 @@ [PcdsFixedAtBuild]
# Point to the MdeModulePkg/Application/UiApp/UiApp.inf
gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c,
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
- ## Xen vlapic's frequence is 100 MHz
- gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
-
# We populate DXE IPL tables with 1G pages preferably on Xen
gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable|TRUE
@@ -471,6 +468,7 @@ [PcdsDynamicDefault]
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x8
+ gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
# Set video resolution for text setup.
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 5732d2188871..87dd4b24679a 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -85,6 +85,7 @@ [Pcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
+ gEfiMdePkgTokenSpaceGuid.PcdFSBClock
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 7524aaa11a29..a29b4e04086e 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -632,5 +632,9 @@ CalibrateLapicTimer (
Freq = DivU64x64Remainder (Dividend, TscTick2 - TscTick, NULL);
DEBUG ((DEBUG_INFO, "APIC Freq % 8lu Hz\n", Freq));
+ ASSERT (Freq <= MAX_UINT32);
+ Status = PcdSet32S (PcdFSBClock, Freq);
+ ASSERT_RETURN_ERROR (Status);
+
UnmapXenPage (SharedInfo);
}
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73278): https://edk2.groups.io/g/devel/message/73278
Mute This Topic: https://groups.io/mt/81605810/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v2 4/7] OvmfPkg/IndustryStandard: Introduce PageTable.h
We are going to use the page table structure in yet another place,
collect the types and macro that can be used from another module
rather that making yet another copy.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
---
CC: Tom Lendacky
CC: Brijesh Singh
---
Notes:
v2:
- new patch
.../IndustryStandard/PageTable.h} | 117 +-
.../BaseMemEncryptSevLib/X64/VirtualMemory.h | 143 +-
2 files changed, 5 insertions(+), 255 deletions(-)
copy OvmfPkg/{Library/BaseMemEncryptSevLib/X64/VirtualMemory.h =>
Include/IndustryStandard/PageTable.h} (60%)
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h
b/OvmfPkg/Include/IndustryStandard/PageTable.h
similarity index 60%
copy from OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h
copy to OvmfPkg/Include/IndustryStandard/PageTable.h
index 996f94f07ebb..e3da4e8cf21c 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h
+++ b/OvmfPkg/Include/IndustryStandard/PageTable.h
@@ -1,6 +1,6 @@
/** @file
- Virtual Memory Management Services to set or clear the memory encryption bit
+ x86_64 Page Tables structures
Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
Copyright (c) 2017 - 2020, AMD Incorporated. All rights reserved.
@@ -11,17 +11,10 @@
**/
-#ifndef __VIRTUAL_MEMORY__
-#define __VIRTUAL_MEMORY__
+#ifndef __PAGE_TABLE_H__
+#define __PAGE_TABLE_H__
-#include
-#include
-#include
-#include
-#include
-#include
-
-#define SYS_CODE64_SEL 0x38
+#include
#pragma pack(1)
@@ -165,106 +158,4 @@ typedef union {
#define PTE_OFFSET(x) ( (x >> 12) & PAGETABLE_ENTRY_MASK)
#define PAGING_1G_ADDRESS_MASK_64 0x000FC000ull
-#define PAGE_TABLE_POOL_ALIGNMENT BASE_2MB
-#define PAGE_TABLE_POOL_UNIT_SIZE SIZE_2MB
-#define PAGE_TABLE_POOL_UNIT_PAGES \
- EFI_SIZE_TO_PAGES (PAGE_TABLE_POOL_UNIT_SIZE)
-#define PAGE_TABLE_POOL_ALIGN_MASK \
- (~(EFI_PHYSICAL_ADDRESS)(PAGE_TABLE_POOL_ALIGNMENT - 1))
-
-typedef struct {
- VOID*NextPool;
- UINTN Offset;
- UINTN FreePages;
-} PAGE_TABLE_POOL;
-
-/**
- Return the pagetable memory encryption mask.
-
- @return The pagetable memory encryption mask.
-
-**/
-UINT64
-EFIAPI
-InternalGetMemEncryptionAddressMask (
- VOID
- );
-
-/**
- This function clears memory encryption bit for the memory region specified by
- PhysicalAddress and Length from the current page table context.
-
- @param[in] Cr3BaseAddress Cr3 Base Address (if zero then use
- current CR3)
- @param[in] PhysicalAddress The physical address that is the start
- address of a memory region.
- @param[in] Length The length of memory region
- @param[in] Flush Flush the caches before applying the
- encryption mask
-
- @retval RETURN_SUCCESS The attributes were cleared for the
- memory region.
- @retval RETURN_INVALID_PARAMETERNumber of pages is zero.
- @retval RETURN_UNSUPPORTED Clearing the memory encyrption attribute
- is not supported
-**/
-RETURN_STATUS
-EFIAPI
-InternalMemEncryptSevSetMemoryDecrypted (
- IN PHYSICAL_ADDRESSCr3BaseAddress,
- IN PHYSICAL_ADDRESSPhysicalAddress,
- IN UINTN Length,
- IN BOOLEAN Flush
- );
-
-/**
- This function sets memory encryption bit for the memory region specified by
- PhysicalAddress and Length from the current page table context.
-
- @param[in] Cr3BaseAddress Cr3 Base Address (if zero then use
- current CR3)
- @param[in] PhysicalAddress The physical address that is the start
- address of a memory region.
- @param[in] Length The length of memory region
- @param[in] Flush Flush the caches before applying the
- encryption mask
-
- @retval RETURN_SUCCESS The attributes were set for the memory
- region.
- @retval RETURN_INVALID_PARAMETERNumber of pages is zero.
- @retval RETURN_UNSUPPORTED Setting the memory encyrption attribute
- is not supported
-**/
-RETURN_STATUS
-EFIAPI
-InternalMemEncryptSevSetMemoryEncrypted (
- IN PHYSICAL_ADDRESSCr3BaseAddress,
- IN PHYSICAL_ADDRESSPhysicalAddress,
- IN UINTN Length,
- IN BOOLEAN Flush
- );
-
-/**
- Returns the encryption state of the specified virtual address range.
-
- @param[in] Cr3BaseAddress Cr3 Base Address (if zero then use
- current C
[edk2-devel] [PATCH v2 1/7] OvmfPkg/XenResetVector: Silent a warning from nasm
To avoid nasm generating a warning, replace the macro by the value expected to be stored in eax. Ia32/XenPVHMain.asm:76: warning: dword data exceeds bounds Reported-by: Laszlo Ersek Signed-off-by: Anthony PERARD Reviewed-by: Laszlo Ersek --- OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm index 2df0f12e18cb..c761e9d30729 100644 --- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm @@ -73,7 +73,7 @@ xenPVHMain: ; ; parameter for Flat32SearchForBfvBase ; -mov eax, ADDR_OF(fourGigabytes) +mov eax, 0 ; ADDR_OF(fourGigabytes) add eax, edx ; add delta ; -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#73272): https://edk2.groups.io/g/devel/message/73272 Mute This Topic: https://groups.io/mt/81605798/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v2 3/7] OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to XEN_VCPU_TIME_INFO
We are going to use new fields from the Xen headers. Apply the EDK2
coding style so that the code that is going to use it doesn't look out
of place.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v2:
- fix case of Tsc* field
OvmfPkg/Include/IndustryStandard/Xen/xen.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/xen.h
b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
index e55d93263285..79a4e212e7c2 100644
--- a/OvmfPkg/Include/IndustryStandard/Xen/xen.h
+++ b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
@@ -183,10 +183,10 @@ struct vcpu_time_info {
* The correct way to interact with the version number is similar to
* Linux's seqlock: see the implementations of read_seqbegin/read_seqretry.
*/
-UINT32 version;
+UINT32 Version;
UINT32 pad0;
-UINT64 tsc_timestamp; /* TSC at last update of time vals. */
-UINT64 system_time; /* Time, in nanosecs, since boot.*/
+UINT64 TscTimestamp; /* TSC at last update of time vals. */
+UINT64 SystemTime; /* Time, in nanosecs, since boot.*/
/*
* Current system time:
* system_time +
@@ -194,11 +194,11 @@ struct vcpu_time_info {
* CPU frequency (Hz):
* ((10^9 << 32) / tsc_to_system_mul) >> tsc_shift
*/
-UINT32 tsc_to_system_mul;
-INT8 tsc_shift;
+UINT32 TscToSystemMultiplier;
+INT8 TscShift;
INT8 pad1[3];
}; /* 32 bytes */
-typedef struct vcpu_time_info vcpu_time_info_t;
+typedef struct vcpu_time_info XEN_VCPU_TIME_INFO;
struct vcpu_info {
/*
@@ -234,7 +234,7 @@ struct vcpu_info {
#endif /* XEN_HAVE_PV_UPCALL_MASK */
xen_ulong_t evtchn_pending_sel;
struct arch_vcpu_info arch;
-struct vcpu_time_info time;
+struct vcpu_time_info Time;
}; /* 64 bytes (x86) */
#ifndef __XEN__
typedef struct vcpu_info vcpu_info_t;
@@ -250,7 +250,7 @@ typedef struct vcpu_info vcpu_info_t;
* of this structure remaining constant.
*/
struct shared_info {
-struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS];
+struct vcpu_info VcpuInfo[XEN_LEGACY_MAX_VCPUS];
/*
* A domain can create "event channels" on which it can send and receive
@@ -299,6 +299,7 @@ struct shared_info {
};
#ifndef __XEN__
typedef struct shared_info shared_info_t;
+typedef struct shared_info XEN_SHARED_INFO;
#endif
/* Turn a plain number into a C UINTN constant. */
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73274): https://edk2.groups.io/g/devel/message/73274
Mute This Topic: https://groups.io/mt/81605801/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v2 2/7] MdePkg: Allow PcdFSBClock to by Dynamic
We are going to want to change the value of PcdFSBClock at run time in OvmfXen, so move it to the PcdsDynamic section. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 Signed-off-by: Anthony PERARD Reviewed-by: Laszlo Ersek Reviewed-by: Liming Gao --- CC: Bob Feng CC: Michael D Kinney CC: Zhiguang Liu --- MdePkg/MdePkg.dec | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index 1d2637acc22a..f0d3b91fc635 100644 --- a/MdePkg/MdePkg.dec +++ b/MdePkg/MdePkg.dec @@ -2257,10 +2257,6 @@ [PcdsFixedAtBuild,PcdsPatchableInModule] # @ValidList 0x8001 | 8, 16, 32 gEfiMdePkgTokenSpaceGuid.PcdPort80DataWidth|8|UINT8|0x002d - ## This value is used to configure X86 Processor FSB clock. - # @Prompt FSB Clock. - gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c - ## The maximum printable number of characters. UefLib functions: AsciiPrint(), AsciiErrorPrint(), # PrintXY(), AsciiPrintXY(), Print(), ErrorPrint() base on this PCD value to print characters. # @Prompt Maximum Printable Number of Characters. @@ -2364,5 +2360,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] # @Prompt Boot Timeout (s) gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0x|UINT16|0x002c + ## This value is used to configure X86 Processor FSB clock. + # @Prompt FSB Clock. + gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c + [UserExtensions.TianoCore."ExtraFiles"] MdePkgExtra.uni -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#73273): https://edk2.groups.io/g/devel/message/73273 Mute This Topic: https://groups.io/mt/81605800/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v2 0/7] OvmfXen: Set PcdFSBClock at runtime
Patch series available in this git branch:
git://xenbits.xen.org/people/aperard/ovmf.git br.apic-timer-freq-v2
Changes in v2:
- main change is to allow mapping of Xen pages outside of the RAM
see patch: "OvmfPkg/XenPlatformPei: Map extra physical address"
- that new function allows to map the Xen shared info page (where we can find
information about tsc frequency) at the highest physical address allowed.
Hi,
OvmfXen uses the APIC timer, but with an hard-coded frequency that may change
as pointed out here:
https://edk2.groups.io/g/devel/message/45185
<20190808134423.ybqg3qkpw5ucfzk4@Air-de-Roger>
This series changes that so the frequency is calculated at runtime.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
There is also one cleanup patch that has nothing to do with the rest.
Cheers,
Anthony PERARD (7):
OvmfPkg/XenResetVector: Silent a warning from nasm
MdePkg: Allow PcdFSBClock to by Dynamic
OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to
XEN_VCPU_TIME_INFO
OvmfPkg/IndustryStandard: Introduce PageTable.h
OvmfPkg/XenPlatformPei: Map extra physical address
OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency
OvmfPkg/OvmfXen: Set PcdFSBClock
MdePkg/MdePkg.dec | 8 +-
OvmfPkg/OvmfXen.dsc | 4 +-
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 4 +
.../IndustryStandard/PageTable.h} | 117 +---
OvmfPkg/Include/IndustryStandard/Xen/xen.h| 17 +-
.../BaseMemEncryptSevLib/X64/VirtualMemory.h | 143 +-
OvmfPkg/XenPlatformPei/Platform.h | 10 +
OvmfPkg/XenPlatformPei/Platform.c | 1 +
OvmfPkg/XenPlatformPei/Xen.c | 252 ++
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm| 2 +-
10 files changed, 287 insertions(+), 271 deletions(-)
copy OvmfPkg/{Library/BaseMemEncryptSevLib/X64/VirtualMemory.h =>
Include/IndustryStandard/PageTable.h} (60%)
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73271): https://edk2.groups.io/g/devel/message/73271
Mute This Topic: https://groups.io/mt/81605796/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] OvmfPkg/XenPlatformPei: Use CPUID to get physical address width on Xen
On Tue, Jan 19, 2021 at 03:49:34PM +0100, Laszlo Ersek wrote: > On 01/19/21 10:37, Julien Grall wrote: > > Hi Igor, > > > > On 13/01/2021 03:42, Igor Druzhinin wrote: > >> We faced a problem with passing through a PCI device with 64GB BAR to > >> UEFI guest. The BAR is expectedly programmed into 64-bit PCI aperture at > >> 64G address which pushes physical address space to 37 bits. That is above > >> 36-bit width that OVMF exposes currently to a guest without tweaking > >> PcdPciMmio64Size knob. > >> > >> The reverse calculation using this knob was inhereted from QEMU-KVM > >> platform > >> code where it serves the purpose of finding max accessible physical > >> address without necessary trusting emulated CPUID physbits value (that > >> could > >> be different from host physbits). On Xen we expect to use CPUID policy > >> to level the data correctly to prevent situations with guest physbits > > >> host physbits e.g. across migrations. > >> > >> The next aspect raising concern - resource consumption for DXE IPL > >> page tables > >> and time required to map the whole address space in case of using CPUID > >> bits directly. That could be mitigated by enabling support for 1G pages > >> in DXE IPL configuration. 1G pages are available on most CPUs produced in > >> the last 10 years and those without don't have many phys bits. > >> > >> Remove all the redundant code now (including PcdPciMmio64.. handling > >> that's > >> not used on Xen anyway) and grab physbits directly from CPUID that should > >> be what baremetal UEFI systems do. > >> > >> Signed-off-by: Igor Druzhinin > > > > Reviewed-by: Julien Grall > > I'm going to hold this patch until Anthony responds in this thread as well: This new patch is fine, I didn't notice that it was a replacement for the previous one. Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#70547): https://edk2.groups.io/g/devel/message/70547 Mute This Topic: https://groups.io/mt/79643470/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] OvmfPkg/XenPlatformPei: Grab 64-bit PCI MMIO hole size from OVMF info table
On Mon, Jan 11, 2021 at 03:45:18AM +, Igor Druzhinin wrote:
> diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c
> b/OvmfPkg/XenPlatformPei/MemDetect.c
> index 1f81eee..4175a2f 100644
> --- a/OvmfPkg/XenPlatformPei/MemDetect.c
> +++ b/OvmfPkg/XenPlatformPei/MemDetect.c
> @@ -227,6 +227,7 @@ GetFirstNonAddress (
>UINT64 FirstNonAddress;
>UINT64 Pci64Base, Pci64Size;
>RETURN_STATUSPcdStatus;
> + EFI_STATUS Status;
>
>FirstNonAddress = BASE_4GB + GetSystemMemorySizeAbove4gb ();
>
> @@ -245,7 +246,10 @@ GetFirstNonAddress (
>// Otherwise, in order to calculate the highest address plus one, we must
>// consider the 64-bit PCI host aperture too. Fetch the default size.
>//
> - Pci64Size = PcdGet64 (PcdPciMmio64Size);
> + Status = XenGetPciMmioInfo (NULL, NULL, , );
Pci64Base is overridden later (25 line bellow) by the value from
FirstNonAddress, shouldn't this be avoided?
Pci64Base = ALIGN_VALUE (FirstNonAddress, (UINT64)SIZE_1GB);
> diff --git a/OvmfPkg/XenPlatformPei/Xen.h b/OvmfPkg/XenPlatformPei/Xen.h
> index 2605481..c6e5fbb 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.h
> +++ b/OvmfPkg/XenPlatformPei/Xen.h
> @@ -34,6 +34,16 @@ typedef struct {
>EFI_PHYSICAL_ADDRESS E820;
>UINT32 E820EntriesCount;
> } EFI_XEN_OVMF_INFO;
> +
> +// This extra table gives layout of PCI apertures in a Xen guest
> +#define OVMF_INFO_PCI_TABLE 0
> +
> +typedef struct {
> + EFI_PHYSICAL_ADDRESS LowStart;
> + EFI_PHYSICAL_ADDRESS LowEnd;
> + EFI_PHYSICAL_ADDRESS HiStart;
> + EFI_PHYSICAL_ADDRESS HiEnd;
In the hvmloader patch, these are uint64. It doesn't seems like a good
idea to use the type EFI_PHYSICAL_ADDRESS here. Could you change to
UINT64 here?
(even if EFI_PHYSICAL_ADDRESS seems to always be UINT64, in the source
code.)
> +} EFI_XEN_OVMF_PCI_INFO;
> #pragma pack()
>
> #endif /* __XEN_H__ */
Thanks,
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#70540): https://edk2.groups.io/g/devel/message/70540
Mute This Topic: https://groups.io/mt/79591397/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 5/5] OvmfPkg/OvmfXen: Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flag
On Fri, Apr 24, 2020 at 08:05:53PM +0200, Laszlo Ersek wrote: > On 04/23/20 11:53, Anthony PERARD wrote: > > [LibraryClasses.common.SEC] > >QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf > > +!ifdef $(DEBUG_ON_HYPERVISOR_CONSOLE) > > + > > DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPortNocheck.inf > > +!else > > > > DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf > > +!endif > > (1) This part can be simplified with an !ifndef, instead, I think. (When > DEBUG_ON_HYPERVISOR_CONSOLE is defined, then the default resolution can > take effect for SEC too.) Sounds good. > If you wish I can change this for you as well. Alternatively, if you'd > rather repost, that's OK too. (And maybe Phil intends to review more of > the patches in this series; I'm not sure.) Feel free to edit on commit. > With (1) updated: > > Reviewed-by: Laszlo Ersek Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58176): https://edk2.groups.io/g/devel/message/58176 Mute This Topic: https://groups.io/mt/73215163/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 4/5] OvmfPkg/PlatformDebugLibIoPort: Introduce a Nocheck variant
On Fri, Apr 24, 2020 at 07:58:48PM +0200, Laszlo Ersek wrote: > On 04/23/20 11:53, Anthony PERARD wrote: > > @@ -24,10 +23,10 @@ [Defines] > > # > > > > [Sources] > > - DebugIoPortQemu.c > > + DebugIoPortNocheck.c > >DebugLib.c > > - DebugLibDetect.h > >DebugLibDetectRom.c > > + DebugLibDetect.h > > (2) The re-ordering of "DebugLibDetect.h" is curious. Maybe you may have > an LC_COLLATE setting that sorts "." after "R"? I think it's more likely that I've copied the .inf that uses "DebugLibDetect.c", edited that line to add "Rom" and forgot to resort the list. > Anyway I can re-sort this when I merge the series. > > Reviewed-by: Laszlo Ersek Thanks. -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58175): https://edk2.groups.io/g/devel/message/58175 Mute This Topic: https://groups.io/mt/73215162/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v2 1/5] OvmfPkg/OvmfXen: Remove DEBUG_ON_SERIAL_PORT
Remove support for DEBUG_ON_SERIAL_PORT because OvmfXen can't be build with it due to a circular dependency: DebugLib: BaseDebugLibSerialPort -> SerialPortLib : XenConsoleSerialPortLib -> XenHypercallLib : XenHypercallLib -> DebugLib Also, if that dependency is fixed, I think it would be harder to find which console the debug is sent to when running an HVM guest. The xen console isn't the serial console used by default. Furthermore, XenHypercallLib isn't initialised early enough, so we would loose debug output from the SEC phase and early PEI phase. Signed-off-by: Anthony PERARD Reviewed-by: Laszlo Ersek --- OvmfPkg/OvmfXen.dsc | 40 +--- 1 file changed, 1 insertion(+), 39 deletions(-) diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc index 47ee8db8b884..4859faf1bff7 100644 --- a/OvmfPkg/OvmfXen.dsc +++ b/OvmfPkg/OvmfXen.dsc @@ -205,17 +205,14 @@ [LibraryClasses] Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf [LibraryClasses.common] BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf [LibraryClasses.common.SEC] QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf -!ifdef $(DEBUG_ON_SERIAL_PORT) - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf -!else DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf -!endif ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf !if $(SOURCE_DEBUG_ENABLE) == TRUE @@ -236,11 +233,6 @@ [LibraryClasses.common.PEI_CORE] ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf -!ifdef $(DEBUG_ON_SERIAL_PORT) - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf -!else - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf -!endif PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf [LibraryClasses.common.PEIM] @@ -252,11 +244,6 @@ [LibraryClasses.common.PEIM] ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf -!ifdef $(DEBUG_ON_SERIAL_PORT) - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf -!else - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf -!endif PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf ResourcePublicationLib|MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.inf ExtractGuidedSectionLib|MdePkg/Library/PeiExtractGuidedSectionLib/PeiExtractGuidedSectionLib.inf @@ -274,11 +261,6 @@ [LibraryClasses.common.DXE_CORE] DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf MemoryAllocationLib|MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf -!ifdef $(DEBUG_ON_SERIAL_PORT) - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf -!else - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf -!endif ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf !if $(SOURCE_DEBUG_ENABLE) == TRUE DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf @@ -292,11 +274,6 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER] DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf ReportStatusCodeLib|MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf -!ifdef $(DEBUG_ON_SERIAL_PORT) - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf -!else - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf -!endif UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf @@ -308,11 +285,6 @@ [LibraryClasses.common.UEFI_DRIVER] DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntry
[edk2-devel] [PATCH v2 5/5] OvmfPkg/OvmfXen: Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flag
Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flag to enable logging debug output to the Xen console. This will work with both Xen HVM guest and Xen PVH guest whereas the default PlatformDebugLibIoPort works only in HVM when QEMU is present. Signed-off-by: Anthony PERARD --- OvmfPkg/OvmfXen.dsc | 13 + 1 file changed, 13 insertions(+) diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc index 4859faf1bff7..0a8fd26990a3 100644 --- a/OvmfPkg/OvmfXen.dsc +++ b/OvmfPkg/OvmfXen.dsc @@ -205,14 +205,22 @@ [LibraryClasses] Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf +!ifdef $(DEBUG_ON_HYPERVISOR_CONSOLE) + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPortNocheck.inf +!else DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf +!endif [LibraryClasses.common] BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf [LibraryClasses.common.SEC] QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf +!ifdef $(DEBUG_ON_HYPERVISOR_CONSOLE) + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPortNocheck.inf +!else DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf +!endif ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf !if $(SOURCE_DEBUG_ENABLE) == TRUE @@ -405,6 +413,11 @@ [PcdsFixedAtBuild] # !include NetworkPkg/NetworkPcds.dsc.inc +!ifdef $(DEBUG_ON_HYPERVISOR_CONSOLE) + ## Set Xen's debug IO port for PlatformDebugLibIoPort + gUefiOvmfPkgTokenSpaceGuid.PcdDebugIoPort|0xe9 +!endif + # IRQs 5, 9, 10, 11 are level-triggered gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20 -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#57944): https://edk2.groups.io/g/devel/message/57944 Mute This Topic: https://groups.io/mt/73215163/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v2 2/5] OvmfPkg/PlatformDebugLibIoPort: Reword QEMU to hypervisor
We are going to reuse PlatformDebugLibIoPort to use debug IO port from hypervisors that aren't QEMU, so reword "QEMU" to "hypervisor" in the descriptions. Signed-off-by: Anthony PERARD --- OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h| 2 +- OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 2 +- OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c| 2 +- OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h index 71a7f33aaf17..4677c85ac3c4 100644 --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h @@ -1,5 +1,5 @@ /** @file - Base Debug library instance for QEMU debug port. + Base Debug library instance for hypervisor debug port. It uses PrintLib to send debug messages to a fixed I/O port. Copyright (c) 2017, Red Hat, Inc. diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c index 3dfa3126c3d0..ec2e677afd8d 100644 --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c @@ -1,5 +1,5 @@ /** @file - Base Debug library instance for QEMU debug port. + Base Debug library instance for hypervisor debug port. It uses PrintLib to send debug messages to a fixed I/O port. Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved. diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c index 2c659e7aea0a..8c466e64e0a6 100644 --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c @@ -1,5 +1,5 @@ /** @file - Detection code for QEMU debug port. + Detection code for hypervisor debug port. Non-SEC instance, caches the result of detection. Copyright (c) 2017, Red Hat, Inc. diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c index 03ba4a0a7b08..8cbdbd94fc0e 100644 --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c @@ -1,5 +1,5 @@ /** @file - Detection code for QEMU debug port. + Detection code for hypervisor debug port. SEC instance, cannot cache the result of detection. Copyright (c) 2017, Red Hat, Inc. -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#57942): https://edk2.groups.io/g/devel/message/57942 Mute This Topic: https://groups.io/mt/73215160/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v2 4/5] OvmfPkg/PlatformDebugLibIoPort: Introduce a Nocheck variant
Introduce PlatformRomDebugLibIoPortNocheck which doesn't try to detect
the debug IO port. Instead, debug logs are always written to the IO port.
Signed-off-by: Anthony PERARD
---
...f => PlatformRomDebugLibIoPortNocheck.inf} | 15 ++-
.../DebugIoPortNocheck.c | 25 +++
2 files changed, 32 insertions(+), 8 deletions(-)
copy OvmfPkg/Library/PlatformDebugLibIoPort/{PlatformRomDebugLibIoPort.inf =>
PlatformRomDebugLibIoPortNocheck.inf} (65%)
create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugIoPortNocheck.c
diff --git
a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPortNocheck.inf
similarity index 65%
copy from OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
copy to
OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPortNocheck.inf
index 8f721d249dd5..34034e1eb887 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
+++
b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPortNocheck.inf
@@ -1,9 +1,8 @@
## @file
-# Instance of Debug Library for the QEMU debug console port.
+# Instance of Debug Library for an hypervisor debug console port.
# It uses Print Library to produce formatted output strings.
#
-# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
-# Copyright (c) 2017, Red Hat, Inc.
+# Copyright (c) 2020, Citrix Systems, Inc.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -12,11 +11,11 @@
[Defines]
INF_VERSION= 0x00010005
- BASE_NAME = PlatformRomDebugLibIoPort
- FILE_GUID = CEB0D9D3-328F-4C24-8C02-28FA1986AE1B
+ BASE_NAME = PlatformRomDebugLibIoPortNocheck
+ FILE_GUID = 92AEB68E-C2CF-466E-9AB2-3F5E713F7DE6
MODULE_TYPE= BASE
VERSION_STRING = 1.0
- LIBRARY_CLASS = DebugLib|SEC
+ LIBRARY_CLASS = DebugLib|SEC PEI_CORE PEIM DXE_CORE
DXE_DRIVER DXE_RUNTIME_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_DRIVER
UEFI_APPLICATION
CONSTRUCTOR= PlatformRomDebugLibIoPortConstructor
#
@@ -24,10 +23,10 @@ [Defines]
#
[Sources]
- DebugIoPortQemu.c
+ DebugIoPortNocheck.c
DebugLib.c
- DebugLibDetect.h
DebugLibDetectRom.c
+ DebugLibDetect.h
[Packages]
MdePkg/MdePkg.dec
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugIoPortNocheck.c
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugIoPortNocheck.c
new file mode 100644
index ..0ef7920a8fb8
--- /dev/null
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugIoPortNocheck.c
@@ -0,0 +1,25 @@
+/** @file
+ Dectection code for hypervisor debug port.
+
+ Copyright (c) 2020, Citrix Systems, Inc.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "DebugLibDetect.h"
+
+/**
+ Always return TRUE without detection as the debug I/O port is always
+ present.
+
+ @retval TRUE The debug I/O port is always present.
+
+**/
+BOOLEAN
+EFIAPI
+PlatformDebugLibIoPortDetect (
+ VOID
+ )
+{
+ return TRUE;
+}
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#57943): https://edk2.groups.io/g/devel/message/57943
Mute This Topic: https://groups.io/mt/73215162/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v2 0/5] OvmfXen: Cleanup debug options
Patch series available in this git branch:
git://xenbits.xen.org/people/aperard/ovmf.git br.ovmfxen-debug-io-v2
v2:
- reuse PlatformDebugLibIoPort rather than duplicate it.
Remove non working DEBUG_ON_SERIAL_PORT, then add a new LibIoPort which always
writes to the IO port.
Issues was discovered and discuss in this mail threads:
"OvmfPkg XenPkg: X64 DEBUG GCC5 -DDEBUG_ON_SERIAL_PORT=TRUE build is broken"
Cheers,
Anthony PERARD (5):
OvmfPkg/OvmfXen: Remove DEBUG_ON_SERIAL_PORT
OvmfPkg/PlatformDebugLibIoPort: Reword QEMU to hypervisor
OvmfPkg/PlatformDebugLibIoPort: factor out debug port detection
OvmfPkg/PlatformDebugLibIoPort: Introduce a Nocheck variant
OvmfPkg/OvmfXen: Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flag
OvmfPkg/OvmfXen.dsc | 49 +--
.../PlatformDebugLibIoPort.inf| 1 +
.../PlatformRomDebugLibIoPort.inf | 1 +
...f => PlatformRomDebugLibIoPortNocheck.inf} | 14 +++---
.../PlatformDebugLibIoPort/DebugLibDetect.h | 8 +--
.../DebugIoPortNocheck.c | 25 ++
.../PlatformDebugLibIoPort/DebugIoPortQemu.c | 34 +
.../Library/PlatformDebugLibIoPort/DebugLib.c | 18 +--
.../PlatformDebugLibIoPort/DebugLibDetect.c | 2 +-
.../DebugLibDetectRom.c | 2 +-
10 files changed, 84 insertions(+), 70 deletions(-)
copy OvmfPkg/Library/PlatformDebugLibIoPort/{PlatformRomDebugLibIoPort.inf =>
PlatformRomDebugLibIoPortNocheck.inf} (65%)
create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugIoPortNocheck.c
create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugIoPortQemu.c
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#57940): https://edk2.groups.io/g/devel/message/57940
Mute This Topic: https://groups.io/mt/73215158/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v2 3/5] OvmfPkg/PlatformDebugLibIoPort: factor out debug port detection
Factor out debug port detection in PlatformDebugLibIoPort.
Signed-off-by: Anthony PERARD
---
.../PlatformDebugLibIoPort.inf| 1 +
.../PlatformRomDebugLibIoPort.inf | 1 +
.../PlatformDebugLibIoPort/DebugLibDetect.h | 6
.../PlatformDebugLibIoPort/DebugIoPortQemu.c | 34 +++
.../Library/PlatformDebugLibIoPort/DebugLib.c | 16 -
5 files changed, 36 insertions(+), 22 deletions(-)
create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugIoPortQemu.c
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
index c09f312ffb1d..94ab9105077a 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
@@ -24,6 +24,7 @@ [Defines]
#
[Sources]
+ DebugIoPortQemu.c
DebugLib.c
DebugLibDetect.c
DebugLibDetect.h
diff --git
a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
index ab27f6327a38..8f721d249dd5 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
@@ -24,6 +24,7 @@ [Defines]
#
[Sources]
+ DebugIoPortQemu.c
DebugLib.c
DebugLibDetect.h
DebugLibDetectRom.c
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
index 4677c85ac3c4..6d08909dbc58 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
@@ -12,12 +12,6 @@
#include
-//
-// The constant value that is read from the debug I/O port
-//
-#define BOCHS_DEBUG_PORT_MAGIC0xE9
-
-
/**
Helper function to return whether the virtual machine has a debug I/O port.
PlatformDebugLibIoPortFound can call this function directly or cache the
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugIoPortQemu.c
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugIoPortQemu.c
new file mode 100644
index ..bf9119807a6c
--- /dev/null
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugIoPortQemu.c
@@ -0,0 +1,34 @@
+/** @file
+ Detection code for QEMU debug port.
+
+ Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
+ Copyright (c) 2012, Red Hat, Inc.
+ Copyright (c) 2020, Citrix Systems, Inc.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include
+#include
+#include "DebugLibDetect.h"
+
+//
+// The constant value that is read from the debug I/O port
+//
+#define BOCHS_DEBUG_PORT_MAGIC0xE9
+
+/**
+ Return the result of detecting the debug I/O port device.
+
+ @retval TRUE if the debug I/O port device was detected.
+ @retval FALSE otherwise
+
+**/
+BOOLEAN
+EFIAPI
+PlatformDebugLibIoPortDetect (
+ VOID
+ )
+{
+ return IoRead8 (PcdGet16 (PcdDebugIoPort)) == BOCHS_DEBUG_PORT_MAGIC;
+}
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
index ec2e677afd8d..dffb20822d18 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
@@ -359,19 +359,3 @@ DebugPrintLevelEnabled (
{
return (BOOLEAN) ((ErrorLevel & PcdGet32(PcdFixedDebugPrintErrorLevel)) !=
0);
}
-
-/**
- Return the result of detecting the debug I/O port device.
-
- @retval TRUE if the debug I/O port device was detected.
- @retval FALSE otherwise
-
-**/
-BOOLEAN
-EFIAPI
-PlatformDebugLibIoPortDetect (
- VOID
- )
-{
- return IoRead8 (PcdGet16 (PcdDebugIoPort)) == BOCHS_DEBUG_PORT_MAGIC;
-}
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#57945): https://edk2.groups.io/g/devel/message/57945
Mute This Topic: https://groups.io/mt/73215166/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/2] OvmfPkg/OvmfXen: Introduce XenDebugLibIoPort
On Tue, Apr 21, 2020 at 03:54:26PM +0200, Laszlo Ersek wrote: > (2) Please write a patch for the following: > > - move the PlatformDebugLibIoPortDetect() function definition to a > separate file called "DebugIoPortQemu.c", On this new file, should I copy the copyright lines from DebugLib.c or should I add a new copyright line? The rest sounds good, I'll prepare all the patches. Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#57804): https://edk2.groups.io/g/devel/message/57804 Mute This Topic: https://groups.io/mt/73153294/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 2/2] OvmfPkg/OvmfXen: Introduce XenDebugLibIoPort
Introduce XenDebugLibIoPort which is enabled with
DEBUG_ON_HYPERVISOR_CONSOLE which send the debug output to Xen's
console.
It's a copy PlatformDebugLibIoPort which always write to the IO port.
It works with both Xen HVM guest and Xen PVH guest whereas the default
PlatformDebugLibIoPort works only in HVM when QEMU is present.
Signed-off-by: Anthony PERARD
---
Notes:
Do you think it would be better to introduce a PCD to
PlatformDebugLibIoPort where we can disable the check
for the debug port and simply always write to it?
OvmfPkg/OvmfXen.dsc | 13
.../PlatformDebugLibIoPort.inf| 6 +++---
.../DebugLibDetect.h | 20 ---
.../DebugLib.c| 16 ---
.../DebugLibDetect.c | 20 ++-
5 files changed, 18 insertions(+), 57 deletions(-)
copy OvmfPkg/Library/{PlatformDebugLibIoPort =>
XenDebugLibIoPort}/PlatformDebugLibIoPort.inf (76%)
copy OvmfPkg/Library/{PlatformDebugLibIoPort =>
XenDebugLibIoPort}/DebugLibDetect.h (57%)
copy OvmfPkg/Library/{PlatformDebugLibIoPort => XenDebugLibIoPort}/DebugLib.c
(94%)
copy OvmfPkg/Library/{PlatformDebugLibIoPort =>
XenDebugLibIoPort}/DebugLibDetect.c (61%)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 4859faf1bff7..8e4d70f21fc8 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -205,14 +205,22 @@ [LibraryClasses]
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
+!ifdef $(DEBUG_ON_HYPERVISOR_CONSOLE)
+ DebugLib|OvmfPkg/Library/XenDebugLibIoPort/PlatformDebugLibIoPort.inf
+!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
[LibraryClasses.common]
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
[LibraryClasses.common.SEC]
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
+!ifdef $(DEBUG_ON_HYPERVISOR_CONSOLE)
+ DebugLib|OvmfPkg/Library/XenDebugLibIoPort/PlatformDebugLibIoPort.inf
+!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
+!endif
ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf
!if $(SOURCE_DEBUG_ENABLE) == TRUE
@@ -405,6 +413,11 @@ [PcdsFixedAtBuild]
#
!include NetworkPkg/NetworkPcds.dsc.inc
+!ifdef $(DEBUG_ON_HYPERVISOR_CONSOLE)
+ ## This flag is used to control the destination port for
PlatformDebugLibIoPort
+ gUefiOvmfPkgTokenSpaceGuid.PcdDebugIoPort|0xe9
+!endif
+
# IRQs 5, 9, 10, 11 are level-triggered
gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
b/OvmfPkg/Library/XenDebugLibIoPort/PlatformDebugLibIoPort.inf
similarity index 76%
copy from OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
copy to OvmfPkg/Library/XenDebugLibIoPort/PlatformDebugLibIoPort.inf
index c09f312ffb1d..141fe7498335 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+++ b/OvmfPkg/Library/XenDebugLibIoPort/PlatformDebugLibIoPort.inf
@@ -12,11 +12,11 @@
[Defines]
INF_VERSION= 0x00010005
- BASE_NAME = PlatformDebugLibIoPort
- FILE_GUID = DF934DA3-CD31-49FE-AF50-B3C87C79325F
+ BASE_NAME = XenDebugLibIoPort
+ FILE_GUID = 201EE63F-79DC-4B8E-953C-FA794C0883A3
MODULE_TYPE= BASE
VERSION_STRING = 1.0
- LIBRARY_CLASS = DebugLib|PEI_CORE PEIM DXE_CORE DXE_DRIVER
DXE_RUNTIME_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_DRIVER UEFI_APPLICATION
+ LIBRARY_CLASS = DebugLib|SEC PEI_CORE PEIM DXE_CORE
DXE_DRIVER DXE_RUNTIME_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_DRIVER
UEFI_APPLICATION
CONSTRUCTOR= PlatformDebugLibIoPortConstructor
#
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
b/OvmfPkg/Library/XenDebugLibIoPort/DebugLibDetect.h
similarity index 57%
copy from OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
copy to OvmfPkg/Library/XenDebugLibIoPort/DebugLibDetect.h
index 71a7f33aaf17..d5ec4063c5be 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
+++ b/OvmfPkg/Library/XenDebugLibIoPort/DebugLibDetect.h
@@ -12,26 +12,6 @@
#include
-//
-// The constant value that is read from the debug I/O port
-//
-#define BOCHS_DEBUG_PORT_MAGIC0xE9
-
-
-/**
- Helper function to return whether the virtual machine has a debug I/O port.
- PlatformDebugLibIoPortFound can call this funct
[edk2-devel] [PATCH 1/2] OvmfPkg/OvmfXen: Remove DEBUG_ON_SERIAL_PORT
Remove support for DEBUG_ON_SERIAL_PORT because OvmfXen can't be build with it due to a circular dependency: DebugLib: BaseDebugLibSerialPort -> SerialPortLib : XenConsoleSerialPortLib -> XenHypercallLib : XenHypercallLib -> DebugLib Also, if that dependency is fixed, I think it would be harder to find which console the debug is sent to when running an HVM guest. The xen console isn't the serial console used by default. Furthermore, XenHypercallLib isn't initialised early enough, so we would loose debug output from the SEC phase and early PEI phase. Signed-off-by: Anthony PERARD --- OvmfPkg/OvmfXen.dsc | 40 +--- 1 file changed, 1 insertion(+), 39 deletions(-) diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc index 47ee8db8b884..4859faf1bff7 100644 --- a/OvmfPkg/OvmfXen.dsc +++ b/OvmfPkg/OvmfXen.dsc @@ -205,17 +205,14 @@ [LibraryClasses] Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf [LibraryClasses.common] BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf [LibraryClasses.common.SEC] QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf -!ifdef $(DEBUG_ON_SERIAL_PORT) - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf -!else DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf -!endif ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf !if $(SOURCE_DEBUG_ENABLE) == TRUE @@ -236,11 +233,6 @@ [LibraryClasses.common.PEI_CORE] ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf -!ifdef $(DEBUG_ON_SERIAL_PORT) - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf -!else - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf -!endif PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf [LibraryClasses.common.PEIM] @@ -252,11 +244,6 @@ [LibraryClasses.common.PEIM] ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf -!ifdef $(DEBUG_ON_SERIAL_PORT) - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf -!else - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf -!endif PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf ResourcePublicationLib|MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.inf ExtractGuidedSectionLib|MdePkg/Library/PeiExtractGuidedSectionLib/PeiExtractGuidedSectionLib.inf @@ -274,11 +261,6 @@ [LibraryClasses.common.DXE_CORE] DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf MemoryAllocationLib|MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf -!ifdef $(DEBUG_ON_SERIAL_PORT) - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf -!else - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf -!endif ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf !if $(SOURCE_DEBUG_ENABLE) == TRUE DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf @@ -292,11 +274,6 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER] DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf ReportStatusCodeLib|MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf -!ifdef $(DEBUG_ON_SERIAL_PORT) - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf -!else - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf -!endif UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf @@ -308,11 +285,6 @@ [LibraryClasses.common.UEFI_DRIVER] DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf MemoryAllocationL
[edk2-devel] [PATCH 0/2] OvmfXen: Cleanup debug options
Patch series available in this git branch:
git://xenbits.xen.org/people/aperard/ovmf.git br.ovmfxen-debug-io-v1
Remove non working DEBUG_ON_SERIAL_PORT, then add a new LibIoPort which always
writes to the IO port.
Issues was discovered and discuss in this mail threads:
"OvmfPkg XenPkg: X64 DEBUG GCC5 -DDEBUG_ON_SERIAL_PORT=TRUE build is broken"
Cheers,
Anthony PERARD (2):
OvmfPkg/OvmfXen: Remove DEBUG_ON_SERIAL_PORT
OvmfPkg/OvmfXen: Introduce XenDebugLibIoPort
OvmfPkg/OvmfXen.dsc | 49 +--
.../PlatformDebugLibIoPort.inf| 6 +--
.../DebugLibDetect.h | 20
.../DebugLib.c| 16 --
.../DebugLibDetect.c | 20 +---
5 files changed, 17 insertions(+), 94 deletions(-)
copy OvmfPkg/Library/{PlatformDebugLibIoPort =>
XenDebugLibIoPort}/PlatformDebugLibIoPort.inf (76%)
copy OvmfPkg/Library/{PlatformDebugLibIoPort =>
XenDebugLibIoPort}/DebugLibDetect.h (57%)
copy OvmfPkg/Library/{PlatformDebugLibIoPort => XenDebugLibIoPort}/DebugLib.c
(94%)
copy OvmfPkg/Library/{PlatformDebugLibIoPort =>
XenDebugLibIoPort}/DebugLibDetect.c (61%)
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#57641): https://edk2.groups.io/g/devel/message/57641
Mute This Topic: https://groups.io/mt/73153287/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] OvmfPkg XenPkg: X64 DEBUG GCC5 -DDEBUG_ON_SERIAL_PORT=TRUE build is broken
between
> > DebugLib
> > // and ourselves.
> > //
> > #define ASSERT(Expression) \
> > do { \
> > if (!(Expression)) {\
> > CpuDeadLoop (); \
> > } \
> > } while (FALSE)
>
> However, XenConsoleSerialPortLib still inherits a DebugLib dependency
> through XenHypercallLib -- but only on IA32/X64, not on ARM/AARCH64! See
> "XenHypercallLib.inf":
>
> > [LibraryClasses.IA32, LibraryClasses.X64]
> > BaseLib
> > HobLib
> > DebugLib
>
> There is no issue without specifying DEBUG_ON_SERIAL_PORT, because
> OvmfXen resolves DebugLib to PlatformDebugLibIoPort then, which does not
> depend on SerialPortLib (thus the cycle is severed).
>
>
> Now, I think there may not be a simple solution for this, because, as
> the message on commit 05480e2fd4ff says, "On a Xen PVH guest, none of
> the existing serial or console interface works".
>
> So even if we eliminated the constructor cycle for this module -- i.e.,
> SerialDxe -- somehow [1], the larger DEBUG_ON_SERIAL_PORT feature might
> not be feasible for *some* module types in OvmfXen. Because,
> XenConsoleSerialPortLib ultimately depends on hypercalls, and I'm unsure
> if those could be used as early as in SEC / PEI.
>
> [1] For breaking up just this one constructor cycle, I guess we could
> remove the DebugLib dependency from XenHypercallLib even on
> IA32/X64.
>
> In other words, I'm not sure if you could send any DEBUG messages *at
> all* to the Xen serial port as early as in SEC or PEI. Meaning that even
> if DEBUG_ON_SERIAL_PORT didn't break the build, it still wouldn't
> (comprehensively) do what its name says.
>
> I figure you attempted the DEBUG_ON_SERIAL_PORT build because without it
> you get no debug output at all (due to the default
> PlatformDebugLibIoPort resolution, which produces no logs on Xen).
>
> For a start, I would recommend removing DEBUG_ON_SERIAL_PORT altogether
> from OvmfXen (to decrease confusion and to eliminate the build
> breakage), and then filing a feature request in the TianoCore bugzilla
> for "some" kind of debug logging in OvmfXen, if the latter is possible.
Thanks Laszlo for the investigation. I usually use DebugLib to debug
OVMF under Xen, I just need to enable the debug port of QEMU. And for
when QEMU isn't available (when running Xen PVH guest), I have a local
patch that I haven't send upstream yet. It's a hacked version of
PlatformDebugLibIoPort which sends logs to Xen's debug port, and doesn't
check if the port is open.
I'll prepare a patch to remove DEBUG_ON_SERIAL_PORT support from OvmfXen
and send my other patch.
Thanks,
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#57627): https://edk2.groups.io/g/devel/message/57627
Mute This Topic: https://groups.io/mt/73015916/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/5] MdePkg: Allow PcdFSBClock to by Dynamic
On Mon, Feb 03, 2020 at 03:34:07PM +, Anthony PERARD wrote: > On Mon, Feb 03, 2020 at 01:34:55AM +, Gao, Liming wrote: > > Anthony: > > This change is OK to me. But if this PCD is configured as Dynamic, its > > value will be got from PCD service. This operation will take some time and > > cause the inaccurate time delay. Have you measured its impact? > > No, I haven't. But I don't think it matter in a Xen guest, the APIC timer is > emulated anyway, so reading from a register of the APIC is going to be > slower than getting the value from the PCD services, I think. > (Hopefully, I'm not too wrong.) > > But I'll give it at measuring the difference, it would be interesting to > know. Now that I've given a try, having the value as Dynamic doesn't change anything in a Xen guest. On my test machine, simply running GetPerformanceCounter (); takes between 1 ns and 2 ns. Reading the dynamic value from PCD on the other hand takes about 350ns. (10ns if it's static.) When I run NanoSecondDelay() with different values, I have: - with static pcd: 63894 ns to delay by 1 ns 66611 ns to delay by 10 ns 43927 ns to delay by 100 ns 71367 ns to delay by 1000 ns 55881 ns to delay by 1 ns 147716 ns to delay by 10 ns 1048335 ns to delay by 100 ns 10041179 ns to delay by 1000 ns - with a dynamic pcd: 40949 ns to delay by 1 ns 84832 ns to delay by 10 ns 82745 ns to delay by 100 ns 59848 ns to delay by 1000 ns 52647 ns to delay by 1 ns 137051 ns to delay by 10 ns 1042492 ns to delay by 100 ns 10036306 ns to delay by 1000 ns So, the kind of PCD used for PcdFSBClock on Xen (with OvmfXen) doesn't really matter. Anyway, thanks for the feedback. -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#53675): https://edk2.groups.io/g/devel/message/53675 Mute This Topic: https://groups.io/mt/70239981/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/5] MdePkg: Allow PcdFSBClock to by Dynamic
On Mon, Feb 03, 2020 at 01:34:55AM +, Gao, Liming wrote: > Anthony: > This change is OK to me. But if this PCD is configured as Dynamic, its > value will be got from PCD service. This operation will take some time and > cause the inaccurate time delay. Have you measured its impact? No, I haven't. But I don't think it matter in a Xen guest, the APIC timer is emulated anyway, so reading from a register of the APIC is going to be slower than getting the value from the PCD services, I think. (Hopefully, I'm not too wrong.) But I'll give it at measuring the difference, it would be interesting to know. Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#53672): https://edk2.groups.io/g/devel/message/53672 Mute This Topic: https://groups.io/mt/70239981/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 4/5] OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency
On Thu, Jan 30, 2020 at 10:12:51AM +0100, Roger Pau Monné wrote: > On Wed, Jan 29, 2020 at 12:12:34PM +0000, Anthony PERARD wrote: > > + Parameters.domid = DOMID_SELF; > > + Parameters.gpfn = (UINTN) PagePtr >> EFI_PAGE_SHIFT; > > + ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap, > > ); > > I'm afraid this will leave a hole in the p2m, and hence freeing the > page back to OVMF is wrong (I assume this is what FreePages does in > CalibrateLapicTimer), as the physical address would be unpopulated > after the call to XENMEM_remove_from_physmap. I guess there's more refactoring to do in OVMF, there are other's of this kind of call, mostly in the PV drivers, XenBusDxe. > > + > > + SharedInfo = AllocatePages (1); > > Hm, it's not the best approach to use a regular memory page to map the > shared info: mapping it is very likely to cause superpage shattering, > and once unmapped it leaves a hole in the p2m. :-( > As a reference you could map the shared info page at maximum physical > address allowed (after checking it's not populated) like Wei is doing > for the Xen on HyperV work. I'll look at what can be done with OVMF. Is there some kind of information that Xen could give? Or is it all information that OVMF should keep track of? Or if Xen only have XENMEM_memory_map, then OVMF already have this information. Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#53579): https://edk2.groups.io/g/devel/message/53579 Mute This Topic: https://groups.io/mt/70239983/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 3/5] OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to XEN_VCPU_TIME_INFO
On Wed, Jan 29, 2020 at 05:14:35PM +0100, Laszlo Ersek wrote: > On 01/29/20 13:12, Anthony PERARD wrote: > Assuming the OVMF platforms continue to build at this stage into the > series, and provided that (1) and (2) are fixed: I'll fix (1) and (2). I've build tests both OvmfXen and OvmfPkgX64, and I've grep for some of those field, and the struct name, so I think ArmVirtXen will also continue to build. > Reviewed-by: Laszlo Ersek Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#53572): https://edk2.groups.io/g/devel/message/53572 Mute This Topic: https://groups.io/mt/70239980/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 3/5] OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to XEN_VCPU_TIME_INFO
We are going to use new fields from the Xen headers. Apply the EDK2
coding style so that the code that is going to use it doesn't look out
of place.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
---
OvmfPkg/Include/IndustryStandard/Xen/xen.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/xen.h
b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
index e55d93263285..ac9155089902 100644
--- a/OvmfPkg/Include/IndustryStandard/Xen/xen.h
+++ b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
@@ -183,10 +183,10 @@ struct vcpu_time_info {
* The correct way to interact with the version number is similar to
* Linux's seqlock: see the implementations of read_seqbegin/read_seqretry.
*/
-UINT32 version;
+UINT32 Version;
UINT32 pad0;
-UINT64 tsc_timestamp; /* TSC at last update of time vals. */
-UINT64 system_time; /* Time, in nanosecs, since boot.*/
+UINT64 TSCTimestamp; /* TSC at last update of time vals. */
+UINT64 SystemTime; /* Time, in nanosecs, since boot.*/
/*
* Current system time:
* system_time +
@@ -194,11 +194,11 @@ struct vcpu_time_info {
* CPU frequency (Hz):
* ((10^9 << 32) / tsc_to_system_mul) >> tsc_shift
*/
-UINT32 tsc_to_system_mul;
-INT8 tsc_shift;
+UINT32 TSCToSystemMultiplier;
+INT8 TSCShift;
INT8 pad1[3];
}; /* 32 bytes */
-typedef struct vcpu_time_info vcpu_time_info_t;
+typedef struct vcpu_time_info XEN_VCPU_TIME_INFO;
struct vcpu_info {
/*
@@ -234,7 +234,7 @@ struct vcpu_info {
#endif /* XEN_HAVE_PV_UPCALL_MASK */
xen_ulong_t evtchn_pending_sel;
struct arch_vcpu_info arch;
-struct vcpu_time_info time;
+struct vcpu_time_info Time;
}; /* 64 bytes (x86) */
#ifndef __XEN__
typedef struct vcpu_info vcpu_info_t;
@@ -250,7 +250,7 @@ typedef struct vcpu_info vcpu_info_t;
* of this structure remaining constant.
*/
struct shared_info {
-struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS];
+struct vcpu_info VcpuInfo[XEN_LEGACY_MAX_VCPUS];
/*
* A domain can create "event channels" on which it can send and receive
@@ -299,6 +299,7 @@ struct shared_info {
};
#ifndef __XEN__
typedef struct shared_info shared_info_t;
+typedef struct shared_info XEN_SHARED_INFO;
#endif
/* Turn a plain number into a C UINTN constant. */
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#53521): https://edk2.groups.io/g/devel/message/53521
Mute This Topic: https://groups.io/mt/70239980/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 0/5] OvmfXen: Set PcdFSBClock at runtime
Patch series available in this git branch: git://xenbits.xen.org/people/aperard/ovmf.git br.apic-timer-freq-v1 Hi, OvmfXen uses the APIC timer, but with an hard-coded frequency that may change as pointed out here: https://edk2.groups.io/g/devel/message/45185 <20190808134423.ybqg3qkpw5ucfzk4@Air-de-Roger> This series changes that so the frequency is calculated at runtime. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 There is also one cleanup patch that has nothing to do with the rest. Cheers, Anthony PERARD (5): OvmfPkg/XenResetVector: Silent a warning from nasm MdePkg: Allow PcdFSBClock to by Dynamic OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to XEN_VCPU_TIME_INFO OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency OvmfPkg/OvmfXen: Set PcdFSBClock MdePkg/MdePkg.dec | 8 +- OvmfPkg/OvmfXen.dsc| 4 +- OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 2 + OvmfPkg/Include/IndustryStandard/Xen/xen.h | 17 +-- OvmfPkg/XenPlatformPei/Platform.h | 5 + OvmfPkg/XenPlatformPei/Platform.c | 1 + OvmfPkg/XenPlatformPei/Xen.c | 127 + OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 2 +- 8 files changed, 150 insertions(+), 16 deletions(-) -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#53520): https://edk2.groups.io/g/devel/message/53520 Mute This Topic: https://groups.io/mt/70239979/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 1/5] OvmfPkg/XenResetVector: Silent a warning from nasm
To avoid nasm generating a warning, replace the macro by the value expected to be stored in eax. Ia32/XenPVHMain.asm:76: warning: dword data exceeds bounds Reported-by: Laszlo Ersek Signed-off-by: Anthony PERARD --- OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm index 2df0f12e18cb..c761e9d30729 100644 --- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm @@ -73,7 +73,7 @@ xenPVHMain: ; ; parameter for Flat32SearchForBfvBase ; -mov eax, ADDR_OF(fourGigabytes) +mov eax, 0 ; ADDR_OF(fourGigabytes) add eax, edx ; add delta ; -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#53519): https://edk2.groups.io/g/devel/message/53519 Mute This Topic: https://groups.io/mt/70239978/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 2/5] MdePkg: Allow PcdFSBClock to by Dynamic
We are going to want to change the value of PcdFSBClock at run time in OvmfXen, so move it to the PcdsDynamic section. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 Signed-off-by: Anthony PERARD --- CC: Bob Feng CC: Liming Gao --- MdePkg/MdePkg.dec | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index d022cc5e3ef2..8f5a48346e50 100644 --- a/MdePkg/MdePkg.dec +++ b/MdePkg/MdePkg.dec @@ -2194,10 +2194,6 @@ [PcdsFixedAtBuild,PcdsPatchableInModule] # @ValidList 0x8001 | 8, 16, 32 gEfiMdePkgTokenSpaceGuid.PcdPort80DataWidth|8|UINT8|0x002d - ## This value is used to configure X86 Processor FSB clock. - # @Prompt FSB Clock. - gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c - ## The maximum printable number of characters. UefLib functions: AsciiPrint(), AsciiErrorPrint(), # PrintXY(), AsciiPrintXY(), Print(), ErrorPrint() base on this PCD value to print characters. # @Prompt Maximum Printable Number of Characters. @@ -2297,5 +2293,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] # @Prompt Boot Timeout (s) gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0x|UINT16|0x002c + ## This value is used to configure X86 Processor FSB clock. + # @Prompt FSB Clock. + gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c + [UserExtensions.TianoCore."ExtraFiles"] MdePkgExtra.uni -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#53522): https://edk2.groups.io/g/devel/message/53522 Mute This Topic: https://groups.io/mt/70239981/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 4/5] OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency
Calculate the frequency of the APIC timer that Xen provides.
Even though the frequency is currently hard-coded, it isn't part of
the public ABI that Xen provides and thus may change at any time. OVMF
needs to determine the frequency by an other mean.
Fortunately, Xen provides a way to determines the frequency of the
TSC, so we can use TSC to calibrate the frequency of the APIC timer.
That information is found in the shared_info page which we map and
unmap once done (XenBusDxe is going to map the page somewhere else).
The calculated frequency is only logged in this patch, it will be used
in a following patch.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
---
CC: Roger Pau Monné
---
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
OvmfPkg/XenPlatformPei/Platform.h | 5 +
OvmfPkg/XenPlatformPei/Platform.c | 1 +
OvmfPkg/XenPlatformPei/Xen.c | 123 ++
4 files changed, 130 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 0ef77db92c03..335a442538c2 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -52,6 +52,7 @@ [LibraryClasses]
DebugLib
HobLib
IoLib
+ LocalApicLib
PciLib
ResourcePublicationLib
PeiServicesLib
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
b/OvmfPkg/XenPlatformPei/Platform.h
index 7661f4a8de0a..97e482a065f0 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -127,6 +127,11 @@ XenGetE820Map (
UINT32 *Count
);
+VOID
+CalibrateLapicTimer (
+ VOID
+ );
+
extern EFI_BOOT_MODE mBootMode;
extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/Platform.c
b/OvmfPkg/XenPlatformPei/Platform.c
index 717fd0ab1a45..e9511eb40c62 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -448,6 +448,7 @@ InitializeXenPlatform (
InitializeRamRegions ();
InitializeXen ();
+ CalibrateLapicTimer ();
if (mBootMode != BOOT_ON_S3_RESUME) {
ReserveEmuVariableNvStore ();
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index c41fecdc486e..d6cdc9a8e31c 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -19,6 +19,7 @@
//
#include
#include
+#include
#include
#include
#include
@@ -386,3 +387,125 @@ InitializeXen (
return EFI_SUCCESS;
}
+
+
+EFI_STATUS
+MapSharedInfoPage (
+ IN VOID *PagePtr
+ )
+{
+ xen_add_to_physmap_t Parameters;
+ INTN ReturnCode;
+
+ Parameters.domid = DOMID_SELF;
+ Parameters.space = XENMAPSPACE_shared_info;
+ Parameters.idx = 0;
+ Parameters.gpfn = (UINTN) PagePtr >> EFI_PAGE_SHIFT;
+ ReturnCode = XenHypercallMemoryOp (XENMEM_add_to_physmap, );
+ if (ReturnCode != 0) {
+return EFI_NO_MAPPING;
+ }
+ return EFI_SUCCESS;
+}
+
+VOID
+UnmapXenPage (
+ IN VOID *PagePtr
+ )
+{
+ xen_remove_from_physmap_t Parameters;
+ INTN ReturnCode;
+
+ Parameters.domid = DOMID_SELF;
+ Parameters.gpfn = (UINTN) PagePtr >> EFI_PAGE_SHIFT;
+ ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap, );
+ ASSERT (ReturnCode == 0);
+}
+
+
+STATIC
+UINT64
+GetCPUFreq (
+ IN XEN_VCPU_TIME_INFO *VcpuTime
+ )
+{
+ UINT32 Version;
+ UINT32 TSCToSystemMultiplier;
+ INT8 TSCShift;
+ UINT64 CPUFreq;
+
+ do {
+Version = VcpuTime->Version;
+MemoryFence ();
+TSCToSystemMultiplier = VcpuTime->TSCToSystemMultiplier;
+TSCShift = VcpuTime->TSCShift;
+MemoryFence ();
+ } while (((Version & 1) != 0) && (Version != VcpuTime->Version));
+
+ CPUFreq = (10ULL << 32) / TSCToSystemMultiplier;
+ if (TSCShift >= 0) {
+ CPUFreq >>= VcpuTime->TSCShift;
+ } else {
+ CPUFreq <<= -VcpuTime->TSCShift;
+ }
+ return CPUFreq;
+}
+
+VOID
+XenDelay (
+ IN XEN_VCPU_TIME_INFO *VcpuTimeInfo,
+ IN UINT64 DelayNs
+ )
+{
+ UINT64 Tick;
+
+ Tick = AsmReadTsc ();
+ Tick += (DelayNs * GetCPUFreq (VcpuTimeInfo)) / 10ULL;
+ while (AsmReadTsc() <= Tick) {
+CpuPause();
+ }
+}
+
+
+/**
+ Calculate the frequency of the Local Apic Timer
+**/
+VOID
+CalibrateLapicTimer (
+ VOID
+ )
+{
+ XEN_SHARED_INFO *SharedInfo;
+ XEN_VCPU_TIME_INFO*VcpuTimeInfo;
+ UINT32TimerTick, TimerTick2;
+ UINT64TscTick, TscTick2;
+ UINT64Freq;
+ EFI_STATUSStatus;
+
+ SharedInfo = AllocatePages (1);
+ Status = MapSharedInfoPage (SharedInfo);
+ ASSERT_EFI_ERROR (Status);
+ if (EFI_ERROR (Status)) {
+goto Exit;
+ }
+
+ VcpuTimeInfo = >VcpuInfo[0].Time;
+
+ InitializeApicTimer (1, MAX_UINT32, TRUE, 0);
+ DisableApicTimerInterrupt ();
+
+ TimerTick = GetApicTimerCurrentCount ();
+ TscTick = AsmReadTsc ();
+ XenDelay (VcpuTimeInfo, 100ULL);
+ TimerTick2
[edk2-devel] [PATCH 5/5] OvmfPkg/OvmfXen: Set PcdFSBClock
Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct
value when SecPeiDxeTimerLibCpu start to use it for the APIC timer.
Currently, nothing appear to use the value in PcdFSBClock before
XenPlatformPei had a chance to set it even though TimerLib is included
in modules runned before XenPlatformPei.
XenPlatformPei doesn't use any of the functions that would use that
value. No other modules in the PEI phase seems to use the TimerLib
before PcdFSBClock is set. There are currently two other modules in
the PEI phase that needs the TimerLib:
- S3Resume2Pei, but only because LocalApicLib needs it, but nothing is
using the value from PcdFSBClock.
- CpuMpPei, but I believe it only runs after XenPlatformPei
Before the PEI phase, there's the SEC phase, and SecMain needs
TimerLib because of LocalApicLib. And it initialise the APIC timers
for the debug agent. But I don't think any of the DebugLib that
OvmfXen could use are actually using the *Delay functions in TimerLib,
and so would not use the value from PcdFSBClock which would be
uninitialised.
A simple runtime test showed that TimerLib doesn't use PcdFSBClock
value before it is set.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
---
OvmfPkg/OvmfXen.dsc | 4 +---
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
OvmfPkg/XenPlatformPei/Xen.c | 4
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 8c11efe9b709..190d7400c148 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -442,9 +442,6 @@ [PcdsFixedAtBuild]
# Point to the MdeModulePkg/Application/UiApp/UiApp.inf
gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c,
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
- ## Xen vlapic's frequence is 100 MHz
- gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
-
#
# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
@@ -468,6 +465,7 @@ [PcdsDynamicDefault]
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x8
+ gEfiMdePkgTokenSpaceGuid.PcdFSBClock
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
# Set video resolution for text setup.
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 335a442538c2..177200f3b7e5 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -83,6 +83,7 @@ [Pcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
+ gEfiMdePkgTokenSpaceGuid.PcdFSBClock
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index d6cdc9a8e31c..fc990462dccc 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -504,6 +504,10 @@ CalibrateLapicTimer (
/ (TscTick2 - TscTick);
DEBUG ((DEBUG_INFO, "APIC Freq % 8lu Hz\n", Freq));
+ ASSERT (Freq <= MAX_UINT32);
+ Status = PcdSet32S (PcdFSBClock, Freq);
+ ASSERT_RETURN_ERROR (Status);
+
UnmapXenPage (SharedInfo);
Exit:
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#53523): https://edk2.groups.io/g/devel/message/53523
Mute This Topic: https://groups.io/mt/70239982/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 60/78] OvmfPkg/Xen: Fix various typos
On Fri, Jan 03, 2020 at 02:42:14PM +0100, Laszlo Ersek wrote: > On 01/03/20 10:07, Philippe Mathieu-Daudé wrote: > > From: Antoine Coeur > > > > Fix various typos in comments and documentation. > > > > Cc: Jordan Justen > > Cc: Laszlo Ersek > > Cc: Ard Biesheuvel > > Cc: Anthony Perard > > Cc: Julien Grall > > Signed-off-by: Antoine Coeur > > Reviewed-by: Philippe Mathieu-Daude > > Signed-off-by: Philippe Mathieu-Daude > > --- > > OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h | 2 +- > > OvmfPkg/Include/IndustryStandard/Xen/grant_table.h| 4 ++-- > > OvmfPkg/Include/IndustryStandard/Xen/io/blkif.h | 2 +- > > OvmfPkg/Include/Protocol/XenBus.h | 4 ++-- > > OvmfPkg/Include/Protocol/XenIo.h | 2 +- > > OvmfPkg/XenBusDxe/DriverBinding.h | 2 +- > > OvmfPkg/XenBusDxe/EventChannel.h | 2 +- > > OvmfPkg/XenBusDxe/GrantTable.h| 2 +- > > OvmfPkg/XenPvBlkDxe/BlockIo.h | 6 +++--- > > OvmfPkg/XenPvBlkDxe/DriverBinding.h | 2 +- > > OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 4 ++-- > > .../XenConsoleSerialPortLib/XenConsoleSerialPortLib.c | 6 +++--- > > OvmfPkg/XenBusDxe/XenBus.c| 2 +- > > OvmfPkg/XenBusDxe/XenBusDxe.c | 6 +++--- > > OvmfPkg/XenBusDxe/XenStore.c | 4 ++-- > > OvmfPkg/XenPvBlkDxe/BlockFront.c | 2 +- > > OvmfPkg/XenPvBlkDxe/BlockIo.c | 8 > > OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c | 2 +- > > 18 files changed, 31 insertions(+), 31 deletions(-) > > So the S-o-b issue pointed out by Anthony for v1 of this patch appears > to have been fixed. > > So, again, once Anthony is happy with this patch, I'll ACK too. Indeed I am: Acked-by: Anthony PERARD Thank you, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#52890): https://edk2.groups.io/g/devel/message/52890 Mute This Topic: https://groups.io/mt/69395959/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [Patch 1/4 V6] BaseTools: Add build option for dependency file generation
On Fri, Dec 06, 2019 at 11:26:55PM +0800, Bob Feng wrote: > BaseTools/Conf/tools_def.template | 181 -- Hi Bob, That patch introduces the first two UTF-8 characters (the quote ’ ) in an otherwise all-ascii file. And that prevent our CI from building OVMF. Part of the error log: Running edk2 build for OvmfPkgX64 build.py... : error 0001: File open failure /home/osstest/build.144860.build-amd64/xen/tools/firmware/ovmf-dir-remote/Conf/tools_def.txt Traceback (most recent call last): File "/home/osstest/build.144860.build-amd64/xen/tools/firmware/ovmf-dir-remote/BaseTools/Source/Python/Common/ToolDefClassObject.py", line 117, in IncludeToolDefFile FileContent = F.readlines() File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 2289: ordinal not in range(128) Full build log can be found here, with ovmf build near the bottom: http://logs.test-lab.xenproject.org/osstest/logs/144860/build-amd64/6.ts-xen-build.log Should we replaces the two offending quotes by proper ascii quotes? Or should we fix IncludeToolDefFile to always use UTF-8 decoding? Or both? Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#52251): https://edk2.groups.io/g/devel/message/52251 Mute This Topic: https://groups.io/mt/67482143/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 61/79] OvmfPkg/Xen: Fix various typos
On Tue, Dec 03, 2019 at 05:15:44PM +0100, Philippe Mathieu-Daude wrote: > From: Antoine Coeur > > Fix various typos in comments and documentation. > > Cc: Jordan Justen > Cc: Laszlo Ersek > Cc: Ard Biesheuvel > Cc: Anthony Perard > Cc: Julien Grall > Reviewed-by: Philippe Mathieu-Daude > Signed-off-by: Philippe Mathieu-Daude There's seems to be missing SoB from Antoine. Could that be added? I might try to send the part of this patch that modify the Xen public headers upstream (the headers in IndustryStandard/Xen). Otherwise, the patch looks fine. Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#51647): https://edk2.groups.io/g/devel/message/51647 Mute This Topic: https://groups.io/mt/65782892/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 60/79] OvmfPkg/Xen: Fix a typo
On Tue, Dec 03, 2019 at 05:15:43PM +0100, Philippe Mathieu-Daude wrote: > Fix a typo in a comment. > > Cc: Jordan Justen > Cc: Laszlo Ersek > Cc: Ard Biesheuvel > Cc: Anthony Perard > Cc: Julien Grall > Signed-off-by: Philippe Mathieu-Daude Acked-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#51646): https://edk2.groups.io/g/devel/message/51646 Mute This Topic: https://groups.io/mt/65782662/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2] OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUE
On Mon, Oct 21, 2019 at 10:13:20PM +0200, Laszlo Ersek wrote: > From: Peter Jones > > Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some > tests check if it's defined or not. Additionally, in UefiPayloadPkg as > well as some other trees, we define it as FALSE in the .dsc file. > > This patch changes all of the Ovmf platforms to explicitly define it as > FALSE by default, and changes all of the checks to test if the value is > TRUE. > > Signed-off-by: Peter Jones > Message-Id: <20190920184507.909884-1-pjo...@redhat.com> > [ler...@redhat.com: drop Contributed-under line, per TianoCore BZ#1373] > [ler...@redhat.com: replace "!= TRUE" with more idiomatic "== FALSE"] > Cc: Andrew Fish > Cc: Anthony Perard > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: Julien Grall > Cc: Leif Lindholm > Cc: Michael Kinney > Cc: Peter Jones > Signed-off-by: Laszlo Ersek Acked-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49333): https://edk2.groups.io/g/devel/message/49333 Mute This Topic: https://groups.io/mt/36365203/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call
On Tue, Sep 17, 2019 at 09:49:22PM +0200, Laszlo Ersek wrote: > Unlike the InstallMultipleProtocolInterfaces() boot service, which takes > an (EFI_HANDLE*) as first parameter, the > UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as > first parameter. > > This is an actual bug. It must have remained hidden until now because it's > on an error path. Fix the UninstallMultipleProtocolInterfaces() call. > > Cc: Anthony Perard > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: Julien Grall > Signed-off-by: Laszlo Ersek Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#47473): https://edk2.groups.io/g/devel/message/47473 Mute This Topic: https://groups.io/mt/34180223/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 11/11] OvmfPkg/XenBusDxe: Fix XenStoreWaitForEvent use during EBS
XenStoreWaitForEvent is going to be called when the ExitBootServices
is signaled, but both CreateEvent and WaitForEvent can't be used.
CreateEvent allocate some memory and WaitForEvent can only be used
when TPL is TPL_APPLICATION.
When ExitBootServices has been called, simply return immediately and
let caller of XenStoreWaitForEvent do a busy loop.
Also cleanup error handling in XenStoreWaitForEvent, WaitForEvent
shouldn't return EFI_UNSUPPORTED anymore.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/XenBusDxe.c | 2 ++
OvmfPkg/XenBusDxe/XenBusDxe.h | 1 +
OvmfPkg/XenBusDxe/XenStore.c | 13 +
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.c b/OvmfPkg/XenBusDxe/XenBusDxe.c
index c71966a666..eb1503ad2b 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.c
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.c
@@ -264,6 +264,8 @@ NotifyExitBoot (
Dev = Context;
+ Dev->ExitBootNotified = TRUE;
+
//
// First, ask every driver using xenbus to disconnect without
// deallocating memory.
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
index 0e91c24338..80162fc3ff 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.h
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
@@ -79,6 +79,7 @@ struct _XENBUS_DEVICE {
EFI_HANDLEControllerHandle;
XENIO_PROTOCOL*XenIo;
EFI_EVENT ExitBootEvent;
+ BOOLEAN ExitBootNotified;
EFI_DEVICE_PATH_PROTOCOL *DevicePath;
LIST_ENTRYChildList;
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index 4026c8a829..4f126109d4 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -401,17 +401,22 @@ XenStoreWaitForEvent (
EFI_EVENT TimerEvent;
EFI_EVENT WaitList[2];
+ //
+ // If the ExitBootServices event have been signaled, simply allow to have
+ // busy loop in the caller.
+ //
+ if (xs.Dev->ExitBootNotified) {
+return EFI_SUCCESS;
+ }
+
gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, );
gBS->SetTimer (TimerEvent, TimerRelative, Timeout);
WaitList[0] = xs.EventChannelEvent;
WaitList[1] = TimerEvent;
Status = gBS->WaitForEvent (2, WaitList, );
- ASSERT (Status != EFI_INVALID_PARAMETER);
+ ASSERT_EFI_ERROR (Status);
gBS->CloseEvent (TimerEvent);
- if (Status == EFI_UNSUPPORTED) {
-return EFI_SUCCESS;
- }
if (Index == 1) {
return EFI_TIMEOUT;
} else {
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#47218): https://edk2.groups.io/g/devel/message/47218
Mute This Topic: https://groups.io/mt/34128216/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 10/11] OvmfPkg/XenPvBlkDxe: Use XenBusIo->RegisterExitCallback
In order to be able to reset the backend before handing it to the next
operating system, it should be reset properly. This patch register a
callback function to be called by XenBusDxe during the
ExitBootServices event.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenPvBlkDxe/BlockFront.c | 37 ---
OvmfPkg/XenPvBlkDxe/BlockFront.h | 12 +-
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c | 4 ++--
3 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c b/OvmfPkg/XenPvBlkDxe/BlockFront.c
index 25a398ccc4..7c166888bd 100644
--- a/OvmfPkg/XenPvBlkDxe/BlockFront.c
+++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c
@@ -309,6 +309,8 @@ XenPvBlockFrontInitialization (
Dev->MediaInfo.Sectors, Dev->MediaInfo.SectorSize));
*DevPtr = Dev;
+
+ XenBusIo->RegisterExitCallback (XenBusIo, XenPvBlockFrontReset, Dev);
return EFI_SUCCESS;
Error2:
@@ -326,13 +328,16 @@ XenPvBlockFrontInitialization (
VOID
XenPvBlockFrontShutdown (
- IN XEN_BLOCK_FRONT_DEVICE *Dev
+ IN XEN_BLOCK_FRONT_DEVICE *Dev,
+ IN BOOLEANResetOnly
)
{
XENBUS_PROTOCOL *XenBusIo = Dev->XenBusIo;
XENSTORE_STATUS Status;
UINT64 Value;
+ XenBusIo->RegisterExitCallback (XenBusIo, NULL, NULL);
+
XenPvBlockSync (Dev);
Status = XenBusIo->SetState (XenBusIo, XST_NIL, XenbusStateClosing);
@@ -393,12 +398,38 @@ XenPvBlockFrontShutdown (
}
Close:
- XenBusIo->UnregisterWatch (XenBusIo, Dev->StateWatchToken);
+ if (!ResetOnly) {
+XenBusIo->UnregisterWatch (XenBusIo, Dev->StateWatchToken);
+ }
XenBusIo->XsRemove (XenBusIo, XST_NIL, "ring-ref");
XenBusIo->XsRemove (XenBusIo, XST_NIL, "event-channel");
XenBusIo->XsRemove (XenBusIo, XST_NIL, "protocol");
- XenPvBlockFree (Dev);
+ if (ResetOnly) {
+XenBusIo->GrantEndAccess (XenBusIo, Dev->RingRef);
+XenBusIo->EventChannelClose (XenBusIo, Dev->EventChannel);
+ } else {
+XenPvBlockFree (Dev);
+ }
+}
+
+/**
+ To be called when ExitBootServices has been called.
+
+ This should reset the PV backend without using memory allocation
+ services.
+**/
+VOID
+EFIAPI
+XenPvBlockFrontReset (
+ IN VOID *Context
+ )
+{
+ XEN_BLOCK_FRONT_DEVICE *Dev;
+
+ Dev = Context;
+
+ XenPvBlockFrontShutdown (Dev, TRUE);
}
STATIC
diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.h b/OvmfPkg/XenPvBlkDxe/BlockFront.h
index 7c2d7f2c9e..ebce4fe434 100644
--- a/OvmfPkg/XenPvBlkDxe/BlockFront.h
+++ b/OvmfPkg/XenPvBlkDxe/BlockFront.h
@@ -67,9 +67,19 @@ XenPvBlockFrontInitialization (
OUT XEN_BLOCK_FRONT_DEVICE **DevPtr
);
+/**
+ @param ResetOnly Set to TRUE when called during the ExitBootServices.
+**/
VOID
XenPvBlockFrontShutdown (
- IN XEN_BLOCK_FRONT_DEVICE *Dev
+ IN XEN_BLOCK_FRONT_DEVICE *Dev,
+ IN BOOLEANResetOnly
+ );
+
+VOID
+EFIAPI
+XenPvBlockFrontReset (
+ IN VOID *Context
);
VOID
diff --git a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c
b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c
index bfe7b1a754..3031406980 100644
--- a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c
+++ b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c
@@ -312,7 +312,7 @@ XenPvBlkDxeDriverBindingStart (
UninitBlockFront:
FreePool (Media);
- XenPvBlockFrontShutdown (Dev);
+ XenPvBlockFrontShutdown (Dev, FALSE);
CloseProtocol:
gBS->CloseProtocol (ControllerHandle, ,
This->DriverBindingHandle, ControllerHandle);
@@ -377,7 +377,7 @@ XenPvBlkDxeDriverBindingStop (
Media = BlockIo->Media;
Dev = XEN_BLOCK_FRONT_FROM_BLOCK_IO (BlockIo);
- XenPvBlockFrontShutdown (Dev);
+ XenPvBlockFrontShutdown (Dev, FALSE);
FreePool (Media);
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#47219): https://edk2.groups.io/g/devel/message/47219
Mute This Topic: https://groups.io/mt/34128218/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 07/11] OvmfPkg/XenBusDxe: Use on stack buffer in internal functions
We will use a buffer on the stack instead of allocating memory for
internal functions that are expecting a reply from xenstore.
The external interface XENBUS_PROTOCOL isn't changed yet, so
allocation are made for XsRead and XsBackendRead.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/XenBus.c | 40 ++--
OvmfPkg/XenBusDxe/XenStore.c | 115 ---
OvmfPkg/XenBusDxe/XenStore.h | 17 +++---
3 files changed, 95 insertions(+), 77 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/XenBus.c b/OvmfPkg/XenBusDxe/XenBus.c
index bb8ddbc4d4..78835ec7b3 100644
--- a/OvmfPkg/XenBusDxe/XenBus.c
+++ b/OvmfPkg/XenBusDxe/XenBus.c
@@ -89,19 +89,18 @@ XenBusReadDriverState (
IN CONST CHAR8 *Path
)
{
- XenbusState State;
- CHAR8 *Ptr = NULL;
+ XenbusState State;
+ CHAR8 Buffer[4];
+ UINTN BufferSize;
XENSTORE_STATUS Status;
- Status = XenStoreRead (XST_NIL, Path, "state", NULL, (VOID **));
+ BufferSize = sizeof (Buffer) - 1;
+ Status = XenStoreRead (XST_NIL, Path, "state", , Buffer);
if (Status != XENSTORE_STATUS_SUCCESS) {
State = XenbusStateClosed;
} else {
-State = AsciiStrDecimalToUintn (Ptr);
- }
-
- if (Ptr != NULL) {
-FreePool (Ptr);
+Buffer[BufferSize] = '\0';
+State = AsciiStrDecimalToUintn (Buffer);
}
return State;
@@ -129,8 +128,11 @@ XenBusAddDevice (
if (XenStorePathExists (XST_NIL, DevicePath, "")) {
XENBUS_PRIVATE_DATA *Child;
-enum xenbus_state State;
-CHAR8 *BackendPath;
+enum xenbus_state State;
+CHAR8 BackendPath[XENSTORE_ABS_PATH_MAX + 1];
+UINTN BackendPathSize;
+
+BackendPathSize = sizeof (BackendPath);
Child = XenBusDeviceInitialized (Dev, DevicePath);
if (Child != NULL) {
@@ -155,17 +157,18 @@ XenBusAddDevice (
}
StatusXenStore = XenStoreRead (XST_NIL, DevicePath, "backend",
- NULL, (VOID **) );
+ , BackendPath);
if (StatusXenStore != XENSTORE_STATUS_SUCCESS) {
DEBUG ((EFI_D_ERROR, "xenbus: %a no backend path.\n", DevicePath));
Status = EFI_NOT_FOUND;
goto out;
}
+BackendPath[BackendPathSize] = '\0';
Private = AllocateCopyPool (sizeof (*Private), );
Private->XenBusIo.Type = AsciiStrDup (Type);
Private->XenBusIo.Node = AsciiStrDup (DevicePath);
-Private->XenBusIo.Backend = BackendPath;
+Private->XenBusIo.Backend = AsciiStrDup (BackendPath);
Private->XenBusIo.DeviceId = (UINT16)AsciiStrDecimalToUintn (Id);
Private->Dev = Dev;
@@ -309,17 +312,20 @@ XenBusSetState (
)
{
enum xenbus_state CurrentState;
- XENSTORE_STATUS Status;
- CHAR8 *Temp;
+ XENSTORE_STATUS Status;
+ CHAR8 Buffer[4];
+ UINTN BufferSize;
+
+ BufferSize = sizeof (Buffer) - 1;
DEBUG ((EFI_D_INFO, "XenBus: Set state to %d\n", NewState));
- Status = XenStoreRead (Transaction, This->Node, "state", NULL, (VOID
**));
+ Status = XenStoreRead (Transaction, This->Node, "state", ,
Buffer);
if (Status != XENSTORE_STATUS_SUCCESS) {
goto Out;
}
- CurrentState = AsciiStrDecimalToUintn (Temp);
- FreePool (Temp);
+ Buffer[BufferSize] = '\0';
+ CurrentState = AsciiStrDecimalToUintn (Buffer);
if (CurrentState == NewState) {
goto Out;
}
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index 004d3b6022..b9588bb8c6 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -756,8 +756,9 @@ XenStoreGetError (
@param RequestTypeThe type of message to send.
@param WriteRequest Pointers to the body sections of the request.
@param NumRequestsThe number of body sections in the request.
- @param LenPtr The returned length of the reply.
- @param ResultPtr The returned body of the reply.
+ @param BufferSize IN: size of the buffer
+OUT: The returned length of the reply.
+ @param Buffer The returned body of the reply.
@return XENSTORE_STATUS_SUCCESS on success. Otherwise an errno indicating
the cause of failure.
@@ -769,15 +770,13 @@ XenStoreTalkv (
IN enum xsd_sockmsg_type RequestType,
IN CONST WRITE_REQUEST *WriteRequest,
IN UINT32 NumRequests,
- OUT UINT32 *LenPtr OPTIONAL,
- OUT VOID**ResultPtr OPTIONAL
+ IN OUT UINTN*BufferSize OPTIONAL,
+ OUT VOID*Buffer OPTIONAL
)
{
struct xsd_sockmsg Message;
UINTN Index;
XENSTORE_STATUSStatus;
- VOID *Buffer;
- UINTN BufferSize;
if (Transaction == XST_NIL) {
Message.tx_id = 0;
@@ -805,32 +804,15 @@ XenStoreTalkv (
}
}
- if (ResultPtr) {
-Buffer =
[edk2-devel] [PATCH 06/11] OvmfPkg/XenBusDxe: Rework XenStoreProcessMessage to avoid allocating memory
This patch rework XenStoreProcessMessage in order to avoid memory
allocation when a reply is expected. Instead of allocating a buffer
for this reply, we are going to copy to a buffer passed by the caller.
For messages that aren't fully received, they will be stored in a
buffer that have been allocated at the initialisation of the driver.
A temporary memory allocation is made in XenStoreTalkv but that will
be removed in a further patch.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/XenStore.c | 297 +++
1 file changed, 130 insertions(+), 167 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index ca7be12d68..004d3b6022 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -72,27 +72,6 @@ struct _XENSTORE_WATCH
#define XENSTORE_WATCH_FROM_LINK(l) \
CR (l, XENSTORE_WATCH, Link, XENSTORE_WATCH_SIGNATURE)
-
-/**
- * Structure capturing messages received from the XenStore service.
- */
-#define XENSTORE_MESSAGE_SIGNATURE SIGNATURE_32 ('X', 'S', 's', 'm')
-typedef struct {
- UINT32 Signature;
- LIST_ENTRY Link;
-
- struct xsd_sockmsg Header;
-
- union {
-/* Queued replies. */
-struct {
- CHAR8 *Body;
-} Reply;
- } u;
-} XENSTORE_MESSAGE;
-#define XENSTORE_MESSAGE_FROM_LINK(r) \
- CR (r, XENSTORE_MESSAGE, Link, XENSTORE_MESSAGE_SIGNATURE)
-
/**
* Container for all XenStore related state.
*/
@@ -105,21 +84,6 @@ typedef struct {
XENBUS_DEVICE *Dev;
- /**
- * A list of replies to our requests.
- *
- * The reply list is filled by xs_rcv_thread(). It
- * is consumed by the context that issued the request
- * to which a reply is made. The requester blocks in
- * XenStoreReadReply ().
- *
- * /note Only one requesting context can be active at a time.
- */
- LIST_ENTRY ReplyList;
-
- /** Lock protecting the reply list. */
- EFI_LOCK ReplyLock;
-
/**
* List of registered watches.
*/
@@ -136,6 +100,13 @@ typedef struct {
/** Handle for XenStore events. */
EFI_EVENT EventChannelEvent;
+
+ /** Buffer used to copy payloads from the xenstore ring */
+ // The + 1 is to allow to have a \0.
+ CHAR8 Buffer[XENSTORE_PAYLOAD_MAX + 1];
+
+ /** ID used when sending messages to xenstored */
+ UINTN NextRequestId;
} XENSTORE_PRIVATE;
//
@@ -148,6 +119,12 @@ static XENSTORE_PRIVATE xs;
// Private Utility Functions
//
+STATIC
+XENSTORE_STATUS
+XenStoreGetError (
+ CONST CHAR8 *ErrorStr
+ );
+
/**
Count and optionally record pointers to a number of NUL terminated
strings in a buffer.
@@ -613,70 +590,106 @@ XenStoreReadStore (
Block reading the next message from the XenStore service and
process the result.
+ @param ExpectedRequestId Block until a reply to with this ID is seen.
+ @param ExpectedTransactionId Idem, but should also match this ID.
+ @param BufferSize IN: size of the buffer
+OUT: The returned length of the reply.
+ @param Buffer The returned body of the reply.
+
@return XENSTORE_STATUS_SUCCESS on success. Otherwise an errno value
indicating the type of failure encountered.
**/
STATIC
XENSTORE_STATUS
XenStoreProcessMessage (
- VOID
+ IN UINT32ExpectedRequestId,
+ IN UINT32ExpectedTransactionId,
+ IN OUT UINTN *BufferSize OPTIONAL,
+ IN OUT CHAR8 *Buffer OPTIONAL
)
{
- XENSTORE_MESSAGE *Message;
- CHAR8 *Body;
- XENSTORE_STATUS Status;
-
- Message = AllocateZeroPool (sizeof (XENSTORE_MESSAGE));
- Message->Signature = XENSTORE_MESSAGE_SIGNATURE;
- Status = XenStoreReadStore (>Header, sizeof (Message->Header));
- if (Status != XENSTORE_STATUS_SUCCESS) {
-FreePool (Message);
-DEBUG ((EFI_D_ERROR, "XenStore: Error read store (%d)\n", Status));
-return Status;
- }
-
- Body = AllocatePool (Message->Header.len + 1);
- Status = XenStoreReadStore (Body, Message->Header.len);
- if (Status != XENSTORE_STATUS_SUCCESS) {
-FreePool (Body);
-FreePool (Message);
-DEBUG ((EFI_D_ERROR, "XenStore: Error read store (%d)\n", Status));
-return Status;
- }
- Body[Message->Header.len] = '\0';
+ struct xsd_sockmsg Header;
+ CHAR8 *Payload;
+ XENSTORE_STATUSStatus;
- if (Message->Header.type == XS_WATCH_EVENT) {
-CONST CHAR8*WatchEventPath;
-CONST CHAR8*WatchEventToken;
-VOID *ConvertedToken;
-XENSTORE_WATCH *Watch;
+ while (TRUE) {
-//
-// Parse WATCH_EVENT messages
-// \0\0
-//
-WatchEventPath = Body;
-WatchEventToken = WatchEventPath + AsciiStrSize (WatchEventPath);
+Status = XenStoreReadStore (, sizeof (Header));
+if (Status != XENSTORE_STATUS_SUCCESS) {
+ DEBUG ((DEBUG_ERROR, "XenStore: Error read store (%d)\n", Status));
+ return Status;
+}
-ConvertedT
[edk2-devel] [PATCH 08/11] OvmfPkg/XenBus: Change XENBUS_PROTOCOL to not return allocated memory
XsRead and XsBackendRead of the XENBUS_PROTOCOL return allocated
memory but this isn't allowed during the ExitBootServices call. We
need XsRead and XsBackendRead to disconnect from the device so
XENBUS_PROTOCOL is changed to use a buffer supplied by a child driver.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Signed-off-by: Anthony PERARD
---
OvmfPkg/Include/Protocol/XenBus.h | 32 --
OvmfPkg/XenBusDxe/XenStore.c | 44 +-
OvmfPkg/XenBusDxe/XenStore.h | 6 +++--
OvmfPkg/XenPvBlkDxe/BlockFront.c | 45 ++-
4 files changed, 54 insertions(+), 73 deletions(-)
diff --git a/OvmfPkg/Include/Protocol/XenBus.h
b/OvmfPkg/Include/Protocol/XenBus.h
index 8ff5ca3575..c22bdfb368 100644
--- a/OvmfPkg/Include/Protocol/XenBus.h
+++ b/OvmfPkg/Include/Protocol/XenBus.h
@@ -35,6 +35,12 @@ typedef struct
#define XST_NIL ((XENSTORE_TRANSACTION *) NULL)
+//
+// When reading a node from xenstore, if the size of the data to be read is
+// unknown, this value can be use for the size of the buffer.
+//
+#define XENSTORE_PAYLOAD_MAX 4096
+
typedef enum {
XENSTORE_STATUS_SUCCESS = 0,
XENSTORE_STATUS_FAIL,
@@ -64,19 +70,17 @@ typedef enum {
///
/**
- Get the contents of the node Node of the PV device. Returns the contents in
- *Result which should be freed after use.
+ Get the contents of the node Node of the PV device.
@param This A pointer to XENBUS_PROTOCOL instance.
@param TransactionThe XenStore transaction covering this request.
@param Node The basename of the file to read.
- @param Result The returned contents from this file.
+ @param BufferSize On input, a pointer to the size of the buffer at
Buffer.
+On output, the size of the data written to Buffer.
+ @param Buffer A pointer to a buffer into which the data read will be
saved.
@return On success, XENSTORE_STATUS_SUCCESS. Otherwise an errno value
indicating the type of failure.
-
- @note The results buffer is malloced and should be free'd by the
-caller.
**/
typedef
XENSTORE_STATUS
@@ -84,23 +88,22 @@ XENSTORE_STATUS
IN XENBUS_PROTOCOL *This,
IN CONST XENSTORE_TRANSACTION *Transaction,
IN CONST CHAR8 *Node,
- OUT VOID **Result
+ IN OUT UINTN *BufferSize,
+ OUT VOID *Buffer
);
/**
- Get the contents of the node Node of the PV device's backend. Returns the
- contents in *Result which should be freed after use.
+ Get the contents of the node Node of the PV device's backend.
@param This A pointer to XENBUS_PROTOCOL instance.
@param TransactionThe XenStore transaction covering this request.
@param Node The basename of the file to read.
- @param Result The returned contents from this file.
+ @param BufferSize On input, a pointer to the size of the buffer at
Buffer.
+On output, the size of the data written to Buffer.
+ @param Buffer A pointer to a buffer into which the data read will be
saved.
@return On success, XENSTORE_STATUS_SUCCESS. Otherwise an errno value
indicating the type of failure.
-
- @note The results buffer is malloced and should be free'd by the
-caller.
**/
typedef
XENSTORE_STATUS
@@ -108,7 +111,8 @@ XENSTORE_STATUS
IN XENBUS_PROTOCOL *This,
IN CONST XENSTORE_TRANSACTION *Transaction,
IN CONST CHAR8 *Node,
- OUT VOID **Result
+ IN OUT UINTN *BufferSize,
+ OUT VOID *Buffer
);
/**
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index b9588bb8c6..cb2d9e1215 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -1336,27 +1336,11 @@ XenBusXenStoreRead (
IN XENBUS_PROTOCOL *This,
IN CONST XENSTORE_TRANSACTION *Transaction,
IN CONST CHAR8 *Node,
- OUT VOID **Value
+ IN OUT UINTN *BufferSize,
+ OUT VOID *Buffer
)
{
- XENSTORE_STATUS Status;
- UINTN BufferSize;
- VOID*Buffer;
-
- BufferSize = XENSTORE_PAYLOAD_MAX + 1;
- Buffer = AllocatePool (BufferSize);
- if (Buffer == NULL) {
-return XENSTORE_STATUS_ENOMEM;
- }
-
- Status = XenStoreRead (Transaction, This->Node, Node, , Buffer);
-
- if (Status == XENSTORE_STATUS_SUCCESS) {
-*Value = Buffer;
- } else {
-FreePool (Buffer);
- }
- return Status;
+ return XenStoreRead (Transaction, This->Node, Node, BufferSize, Buffer);
}
XENSTORE_STATUS
@@ -1365,27 +1349,11 @@ XenBusXenStoreBackendRead (
IN XENBUS_PROTOCOL *This,
IN CONST XENSTORE_TRANSACTION *Transaction,
IN CONST CHAR8 *Node,
- OUT VOID **Value
+ IN OUT UINTN *BufferSize,
+ OUT VOID *
[edk2-devel] [PATCH 00/11] OvmfPkg/XenBusDxe: Fix ExitBootServices handler to avoid allocation
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190 Patch series available in this git branch: https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.xenbusdxe-fix-exitbootservices-v1 Hi, This patch series works toward removing usage of Memory Allocation Services in XenBusDxe when ExitBootServices() is called by the next operating system. Since that in order to reset a backend, communication needs to happened via xenstore, this series focus mostly on getting rid of allocation in the xenstore driver. There are still some left but that's in function that aren't needed after EBS is called. In some places (like XenStoreVSPrint), instead of allocating a buffer, the buffer (4k) is on the stack. Thanks, Anthony PERARD (11): OvmfPkg/XenBusDxe: Fix missing \n in DEBUG messages OvmfPkg/XenBusDxe: Have XenStoreFindWatch take a pointer OvmfPkg/XenBusDxe: Rework watch events reception OvmfPkg/XenBusDxe: Avoid Allocate in XenStoreVSPrint OvmfPkg/XenBusDxe: Construct paths without allocation OvmfPkg/XenBusDxe: Rework XenStoreProcessMessage to avoid allocating memory OvmfPkg/XenBusDxe: Use on stack buffer in internal functions OvmfPkg/XenBus: Change XENBUS_PROTOCOL to not return allocated memory OvmfPkg/XenBusDxe: Fix NotifyExitBoot to avoid Memory Allocation Services OvmfPkg/XenPvBlkDxe: Use XenBusIo->RegisterExitCallback OvmfPkg/XenBusDxe: Fix XenStoreWaitForEvent use during EBS OvmfPkg/Include/Protocol/XenBus.h | 67 +++- OvmfPkg/XenBusDxe/EventChannel.c | 3 +- OvmfPkg/XenBusDxe/XenBus.c| 58 ++- OvmfPkg/XenBusDxe/XenBusDxe.c | 29 +- OvmfPkg/XenBusDxe/XenBusDxe.h | 3 + OvmfPkg/XenBusDxe/XenStore.c | 577 +- OvmfPkg/XenBusDxe/XenStore.h | 44 ++- OvmfPkg/XenPvBlkDxe/BlockFront.c | 82 +++-- OvmfPkg/XenPvBlkDxe/BlockFront.h | 12 +- OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c | 4 +- 10 files changed, 483 insertions(+), 396 deletions(-) -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#47208): https://edk2.groups.io/g/devel/message/47208 Mute This Topic: https://groups.io/mt/34128009/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 02/11] OvmfPkg/XenBusDxe: Have XenStoreFindWatch take a pointer
Rework XenStoreFindWatch() to be able to search for a registered watch
with a pointer instead of a string.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/XenStore.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index 7253d8ae37..727641a0fe 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -253,14 +253,12 @@ Split (
STATIC
XENSTORE_WATCH *
XenStoreFindWatch (
- IN CONST CHAR8 *Token
+ IN VOID *Token
)
{
- XENSTORE_WATCH *Watch, *WantedWatch;
+ XENSTORE_WATCH *Watch;
LIST_ENTRY *Entry;
- WantedWatch = (VOID *) AsciiStrHexToUintn (Token);
-
if (IsListEmpty ()) {
return NULL;
}
@@ -268,7 +266,7 @@ XenStoreFindWatch (
!IsNull (, Entry);
Entry = GetNextNode (, Entry)) {
Watch = XENSTORE_WATCH_FROM_LINK (Entry);
-if (Watch == WantedWatch)
+if ((VOID *) Watch == Token)
return Watch;
}
@@ -632,12 +630,16 @@ XenStoreProcessMessage (
Body[Message->Header.len] = '\0';
if (Message->Header.type == XS_WATCH_EVENT) {
+VOID *ConvertedToken;
+
Message->u.Watch.Vector = Split(Body, Message->Header.len,
>u.Watch.VectorSize);
+ConvertedToken =
+ (VOID *) AsciiStrHexToUintn (Message->u.Watch.Vector[XS_WATCH_TOKEN]);
+
EfiAcquireLock ();
-Message->u.Watch.Handle =
- XenStoreFindWatch (Message->u.Watch.Vector[XS_WATCH_TOKEN]);
+Message->u.Watch.Handle = XenStoreFindWatch (ConvertedToken);
DEBUG ((EFI_D_INFO, "XenStore: Watch event %a\n",
Message->u.Watch.Vector[XS_WATCH_TOKEN]));
if (Message->u.Watch.Handle != NULL) {
@@ -1384,8 +1386,7 @@ XenStoreUnregisterWatch (
ASSERT (Watch->Signature == XENSTORE_WATCH_SIGNATURE);
- AsciiSPrint (Token, sizeof (Token), "%p", (VOID *) Watch);
- if (XenStoreFindWatch (Token) == NULL) {
+ if (XenStoreFindWatch (Watch) == NULL) {
return;
}
@@ -1393,6 +1394,7 @@ XenStoreUnregisterWatch (
RemoveEntryList (>Link);
EfiReleaseLock ();
+ AsciiSPrint (Token, sizeof (Token), "%p", (VOID *) Watch);
XenStoreUnwatch (Watch->Node, Token);
/* Cancel pending watch events. */
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#47211): https://edk2.groups.io/g/devel/message/47211
Mute This Topic: https://groups.io/mt/34128012/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 01/11] OvmfPkg/XenBusDxe: Fix missing \n in DEBUG messages
Fix missing \n in DEBUG messages in XenBusDxe and use DEBUG_*.
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/EventChannel.c | 3 ++-
OvmfPkg/XenBusDxe/XenStore.c | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/EventChannel.c b/OvmfPkg/XenBusDxe/EventChannel.c
index 6900071782..c6b3871781 100644
--- a/OvmfPkg/XenBusDxe/EventChannel.c
+++ b/OvmfPkg/XenBusDxe/EventChannel.c
@@ -44,7 +44,8 @@ XenBusEventChannelAllocate (
EVTCHNOP_alloc_unbound,
);
if (ReturnCode != 0) {
-DEBUG ((EFI_D_ERROR, "ERROR: alloc_unbound failed with rc=%d",
ReturnCode));
+DEBUG ((DEBUG_ERROR, "ERROR: alloc_unbound failed with rc=%d\n",
+ReturnCode));
return ReturnCode;
}
*Port = Parameter.port;
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index 34890ae40b..7253d8ae37 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -738,7 +738,7 @@ XenStoreReadReply (
XENSTORE_STATUS Status;
Status = XenStoreProcessMessage ();
if (Status != XENSTORE_STATUS_SUCCESS && Status != XENSTORE_STATUS_EAGAIN)
{
- DEBUG ((EFI_D_ERROR, "XenStore, error while reading the ring (%d).",
+ DEBUG ((DEBUG_ERROR, "XenStore, error while reading the ring (%d).\n",
Status));
return Status;
}
@@ -1076,7 +1076,7 @@ XenStoreDeinit (
if (!IsListEmpty ()) {
XENSTORE_WATCH *Watch;
LIST_ENTRY *Entry;
-DEBUG ((EFI_D_WARN, "XenStore: RegisteredWatches is not empty, cleaning
up..."));
+DEBUG ((DEBUG_WARN, "XenStore: RegisteredWatches is not empty, cleaning
up...\n"));
Entry = GetFirstNode ();
while (!IsNull (, Entry)) {
Watch = XENSTORE_WATCH_FROM_LINK (Entry);
@@ -1092,7 +1092,7 @@ XenStoreDeinit (
//
if (!IsListEmpty ()) {
LIST_ENTRY *Entry;
-DEBUG ((EFI_D_WARN, "XenStore: WatchEvents is not empty, cleaning up..."));
+DEBUG ((DEBUG_WARN, "XenStore: WatchEvents is not empty, cleaning
up...\n"));
Entry = GetFirstNode ();
while (!IsNull (, Entry)) {
XENSTORE_MESSAGE *Message = XENSTORE_MESSAGE_FROM_LINK (Entry);
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#47209): https://edk2.groups.io/g/devel/message/47209
Mute This Topic: https://groups.io/mt/34128010/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 03/11] OvmfPkg/XenBusDxe: Rework watch events reception
This patch rework the reception of xenstore watch event to avoid
allocation.
Instead of queuing watch events, we simply mark a XENSTORE_WATCH as
"triggered". We don't need to know how many time we received the
event, only that it happened. That avoid to allocate a
XENSTORE_MESSAGE for every watch events.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/XenStore.c | 125 ++-
1 file changed, 35 insertions(+), 90 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index 727641a0fe..5cc900190a 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -65,6 +65,8 @@ struct _XENSTORE_WATCH
/* Path being watched. */
CHAR8 *Node;
+
+ BOOLEAN Triggered;
};
#define XENSTORE_WATCH_FROM_LINK(l) \
@@ -86,13 +88,6 @@ typedef struct {
struct {
CHAR8 *Body;
} Reply;
-
-/* Queued watch events. */
-struct {
- XENSTORE_WATCH *Handle;
- CONST CHAR8 **Vector;
- UINT32 VectorSize;
-} Watch;
} u;
} XENSTORE_MESSAGE;
#define XENSTORE_MESSAGE_FROM_LINK(r) \
@@ -133,14 +128,6 @@ typedef struct {
/** Lock protecting the registered watches list. */
EFI_LOCK RegisteredWatchesLock;
- /**
- * List of pending watch callback events.
- */
- LIST_ENTRY WatchEvents;
-
- /** Lock protecting the watch calback list. */
- EFI_LOCK WatchEventsLock;
-
/**
* The event channel for communicating with the
* XenStore service.
@@ -630,29 +617,32 @@ XenStoreProcessMessage (
Body[Message->Header.len] = '\0';
if (Message->Header.type == XS_WATCH_EVENT) {
-VOID *ConvertedToken;
+CONST CHAR8*WatchEventPath;
+CONST CHAR8*WatchEventToken;
+VOID *ConvertedToken;
+XENSTORE_WATCH *Watch;
-Message->u.Watch.Vector = Split(Body, Message->Header.len,
->u.Watch.VectorSize);
+//
+// Parse WATCH_EVENT messages
+// \0\0
+//
+WatchEventPath = Body;
+WatchEventToken = WatchEventPath + AsciiStrSize (WatchEventPath);
-ConvertedToken =
- (VOID *) AsciiStrHexToUintn (Message->u.Watch.Vector[XS_WATCH_TOKEN]);
+ConvertedToken = (VOID *) AsciiStrHexToUintn (WatchEventToken);
EfiAcquireLock ();
-Message->u.Watch.Handle = XenStoreFindWatch (ConvertedToken);
-DEBUG ((EFI_D_INFO, "XenStore: Watch event %a\n",
-Message->u.Watch.Vector[XS_WATCH_TOKEN]));
-if (Message->u.Watch.Handle != NULL) {
- EfiAcquireLock ();
- InsertHeadList (, >Link);
- EfiReleaseLock ();
+Watch = XenStoreFindWatch (ConvertedToken);
+DEBUG ((DEBUG_INFO, "XenStore: Watch event %a\n", WatchEventToken));
+if (Watch != NULL) {
+ Watch->Triggered = TRUE;
} else {
DEBUG ((EFI_D_WARN, "XenStore: Watch handle %a not found\n",
- Message->u.Watch.Vector[XS_WATCH_TOKEN]));
- FreePool((VOID*)Message->u.Watch.Vector);
- FreePool(Message);
+ WatchEventToken));
}
EfiReleaseLock ();
+FreePool (Message);
+FreePool (Body);
} else {
Message->u.Reply.Body = Body;
EfiAcquireLock ();
@@ -936,40 +926,29 @@ XenStoreUnwatch (
STATIC
XENSTORE_STATUS
XenStoreWaitWatch (
- VOID *Token
+ IN VOID *Token
)
{
- XENSTORE_MESSAGE *Message;
- LIST_ENTRY *Entry = NULL;
- LIST_ENTRY *Last = NULL;
+ XENSTORE_WATCH *Watch;
XENSTORE_STATUS Status;
+ EfiAcquireLock ();
+ Watch = XenStoreFindWatch (Token);
+ EfiReleaseLock ();
+ if (Watch == NULL) {
+return XENSTORE_STATUS_EINVAL;
+ }
+
while (TRUE) {
-EfiAcquireLock ();
-if (IsListEmpty () ||
-Last == GetFirstNode ()) {
- EfiReleaseLock ();
- Status = XenStoreProcessMessage ();
- if (Status != XENSTORE_STATUS_SUCCESS && Status !=
XENSTORE_STATUS_EAGAIN) {
-return Status;
- }
- continue;
+if (Watch->Triggered) {
+ Watch->Triggered = FALSE;
+ return XENSTORE_STATUS_SUCCESS;
}
-for (Entry = GetFirstNode ();
- Entry != Last && !IsNull (, Entry);
- Entry = GetNextNode (, Entry)) {
- Message = XENSTORE_MESSAGE_FROM_LINK (Entry);
- if (Message->u.Watch.Handle == Token) {
-RemoveEntryList (Entry);
-EfiReleaseLock ();
-FreePool((VOID*)Message->u.Watch.Vector);
-FreePool(Message);
-return XENSTORE_STATUS_SUCCESS;
- }
+Status = XenStoreProcessMessage ();
+if (Status != XENSTORE_STATUS_SUCCESS && Status != XENSTORE_STATUS_EAGAIN)
{
+ return Status;
}
-Last = GetFirstNode ();
-EfiReleaseLock ();
}
}
@@ -1052,12 +1031,10 @@ XenStoreInit (
xs.XenStore, xs.EventChannel));
InitializeListHead ();
- InitializeListHead ();
InitializeListHead ();
EfiIniti
[edk2-devel] [PATCH 09/11] OvmfPkg/XenBusDxe: Fix NotifyExitBoot to avoid Memory Allocation Services
This patch fix the EVT_SIGNAL_EXIT_BOOT_SERVICES handler to avoid
using the Memory Allocation Services.
This comes with a new interface named RegisterExitCallback so that PV
drivers can disconnect from the backend before XenBusDxe is teared
down.
Instead of using Disconnect() to tear down the XenBus driver and the
children drivers, we are going to ask every driver using
XENBUS_PROTOCOL to disconnect from the hardware via the callback set
with RegisterExitCallback, then reset the xenstore shared ring and
the grant table.
Since there are no driver using RegisterExitCallback yet, no driver are
going to be disconnected. Linux can deal with that. And that will be
fixed by the next patch with a change for XenPvBlkDxe.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Signed-off-by: Anthony PERARD
---
OvmfPkg/Include/Protocol/XenBus.h | 35 +++
OvmfPkg/XenBusDxe/XenBus.c| 18
OvmfPkg/XenBusDxe/XenBusDxe.c | 27 +---
OvmfPkg/XenBusDxe/XenBusDxe.h | 2 ++
OvmfPkg/XenBusDxe/XenStore.c | 22 ++-
OvmfPkg/XenBusDxe/XenStore.h | 21 +++
6 files changed, 121 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/Include/Protocol/XenBus.h
b/OvmfPkg/Include/Protocol/XenBus.h
index c22bdfb368..04986747c8 100644
--- a/OvmfPkg/Include/Protocol/XenBus.h
+++ b/OvmfPkg/Include/Protocol/XenBus.h
@@ -373,6 +373,38 @@ XENSTORE_STATUS
IN VOID *Token
);
+typedef
+VOID
+(EFIAPI *XENBUS_EXIT_CALLBACK)(
+ IN VOID *Context
+ );
+
+/**
+ Register a function to be called during the ExitBootServices event.
+
+ NotifyFunction will be called when XenBusDxe is notified of
+ EVT_SIGNAL_EXIT_BOOT_SERVICES. The function should follow the same
+ requirements as if it as registered an event on
+ EVT_SIGNAL_EXIT_BOOT_SERVICES, i.e. no use of the Memory Allocation
+ Services.
+
+ To unregister the function, call RegisterExitCallback with
+ NotifyFunction=NULL.
+
+ @note There can only be one callback per driver.
+
+ @param This A pointer to the XENBUS_PROTOCOL.
+ @param NotifyFunction The function to be called.
+ @param NotifyContextA context.
+**/
+typedef
+VOID
+(EFIAPI *XENBUS_SET_EXIT_CALLBACK) (
+ IN XENBUS_PROTOCOL *This,
+ IN XENBUS_EXIT_CALLBACK NotifyFunction,
+ IN VOID *NotifyContext
+ );
+
///
/// Protocol structure
@@ -400,6 +432,9 @@ struct _XENBUS_PROTOCOL {
XENBUS_REGISTER_WATCH_BACKEND RegisterWatchBackend;
XENBUS_UNREGISTER_WATCH UnregisterWatch;
XENBUS_WAIT_FOR_WATCH WaitForWatch;
+
+ XENBUS_SET_EXIT_CALLBACK RegisterExitCallback;
+
//
// Protocol data fields
//
diff --git a/OvmfPkg/XenBusDxe/XenBus.c b/OvmfPkg/XenBusDxe/XenBus.c
index 78835ec7b3..54166505d2 100644
--- a/OvmfPkg/XenBusDxe/XenBus.c
+++ b/OvmfPkg/XenBusDxe/XenBus.c
@@ -343,6 +343,23 @@ XenBusSetState (
return Status;
}
+STATIC
+VOID
+EFIAPI
+XenBusRegisterExitCallback (
+ IN XENBUS_PROTOCOL *This,
+ IN XENBUS_EXIT_CALLBACK NotifyFunction,
+ IN VOID *NotifyContext
+ )
+{
+ XENBUS_PRIVATE_DATA *Dev;
+
+ Dev = XENBUS_PRIVATE_DATA_FROM_THIS (This);
+
+ Dev->ExitCallback = NotifyFunction;
+ Dev->ExitCallbackContext = NotifyContext;
+}
+
STATIC XENBUS_PRIVATE_DATA gXenBusPrivateData = {
XENBUS_PRIVATE_DATA_SIGNATURE,// Signature
{ NULL, NULL }, // Link
@@ -364,6 +381,7 @@ STATIC XENBUS_PRIVATE_DATA gXenBusPrivateData = {
XenBusRegisterWatchBackend, // XenBusIo.RegisterWatchBackend
XenBusUnregisterWatch, // XenBusIo.UnregisterWatch
XenBusWaitForWatch, // XenBusIo.WaitForWatch
+XenBusRegisterExitCallback, // XenBusIo.RegisterExitCallback
NULL, // XenBusIo.Type
0, // XenBusIo.DeviceId
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.c b/OvmfPkg/XenBusDxe/XenBusDxe.c
index 634c7b71eb..c71966a666 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.c
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.c
@@ -258,10 +258,31 @@ NotifyExitBoot (
IN VOID *Context
)
{
- XENBUS_DEVICE *Dev = Context;
+ XENBUS_DEVICE *Dev;
+ LIST_ENTRY *Entry;
+ XENBUS_PRIVATE_DATA *Child;
- gBS->DisconnectController(Dev->ControllerHandle,
-Dev->This->DriverBindingHandle, NULL);
+ Dev = Context;
+
+ //
+ // First, ask every driver using xenbus to disconnect without
+ // deallocating memory.
+ //
+ for (Entry = GetFirstNode (>ChildList);
+ !IsNodeAtEnd (>ChildList, Entry);
+ Entry = GetNextNode (>ChildList, Entry)) {
+Child = XENBUS_PRIVATE_DATA_FROM_LINK (Entry);
+if (Child->ExitCallback != NULL) {
+ Child->ExitCallback (Child->ExitCallbackContext);
+}
+ }
+
+ //
+ // Now, we can reset the devices used by XenBusDxe.
+ //
+ XenStoreResetW
[edk2-devel] [PATCH v5 23/35] OvmfPkg/XenPlatformPei: Rework memory detection
When running as a Xen PVH guest, there is no CMOS to read the memory
size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
work without CMOS by reading the e820 table.
Rework XenPublishRamRegions to also care for the reserved and ACPI
entry in the e820 table. The region that was added by InitializeXen()
isn't needed as that same entry is in the e820 table provided by
hvmloader.
MTRR settings aren't modified anymore, on HVM it's already done by
hvmloader, on PVH it is supposed to have sane default. MTRR will need
to be done properly but keeping what's already been done by programs
that have run before OVMF will do for now.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v5:
- fix coding style
- fix typo in commit message
- Handle all possible cases of a E820 reserved range overlapping with the
LAPIC range.
v4:
- some coding style
- Added AddReservedMemoryRangeHob, and using it.
- this patch now replace "OvmfPkg/XenPlatformPei: Reserve hvmloader's
memory only when it has run"
from v3. hvmloader have added an entry in the e820 table, there is no
need for a special case.
- now, everything that is in the e820 table is added to OVMF's memory
map, no more skipping ACPI entries or hvmloader's reserved entries.
Instead, we look for the local APIC region and avoid it if it is
present in the e820.
- rework commit message
OvmfPkg/XenPlatformPei/Platform.h | 13 ++
OvmfPkg/XenPlatformPei/MemDetect.c | 69 +++
OvmfPkg/XenPlatformPei/Platform.c | 11 +
OvmfPkg/XenPlatformPei/Xen.c | 75 +-
4 files changed, 147 insertions(+), 21 deletions(-)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
b/OvmfPkg/XenPlatformPei/Platform.h
index db9a62572f..7661f4a8de 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -44,6 +44,13 @@ AddReservedMemoryBaseSizeHob (
BOOLEAN Cacheable
);
+VOID
+AddReservedMemoryRangeHob (
+ EFI_PHYSICAL_ADDRESSMemoryBase,
+ EFI_PHYSICAL_ADDRESSMemoryLimit,
+ BOOLEAN Cacheable
+ );
+
VOID
AddressWidthInitialization (
VOID
@@ -114,6 +121,12 @@ XenPublishRamRegions (
VOID
);
+EFI_STATUS
+XenGetE820Map (
+ EFI_E820_ENTRY64 **Entries,
+ UINT32 *Count
+ );
+
extern EFI_BOOT_MODE mBootMode;
extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c
b/OvmfPkg/XenPlatformPei/MemDetect.c
index cf95f9c474..1f81eee407 100644
--- a/OvmfPkg/XenPlatformPei/MemDetect.c
+++ b/OvmfPkg/XenPlatformPei/MemDetect.c
@@ -96,6 +96,45 @@ Q35TsegMbytesInitialization (
mQ35TsegMbytes = ExtendedTsegMbytes;
}
+STATIC
+UINT64
+GetHighestSystemMemoryAddress (
+ BOOLEAN Below4gb
+ )
+{
+ EFI_E820_ENTRY64*E820Map;
+ UINT32 E820EntriesCount;
+ EFI_E820_ENTRY64*Entry;
+ EFI_STATUS Status;
+ UINT32 Loop;
+ UINT64 HighestAddress;
+ UINT64 EntryEnd;
+
+ HighestAddress = 0;
+
+ Status = XenGetE820Map (, );
+ ASSERT_EFI_ERROR (Status);
+
+ for (Loop = 0; Loop < E820EntriesCount; Loop++) {
+Entry = E820Map + Loop;
+EntryEnd = Entry->BaseAddr + Entry->Length;
+
+if (Entry->Type == EfiAcpiAddressRangeMemory &&
+EntryEnd > HighestAddress) {
+
+ if (Below4gb && (EntryEnd <= BASE_4GB)) {
+HighestAddress = EntryEnd;
+ } else if (!Below4gb && (EntryEnd >= BASE_4GB)) {
+HighestAddress = EntryEnd;
+ }
+}
+ }
+
+ //
+ // Round down the end address.
+ //
+ return HighestAddress & ~(UINT64)EFI_PAGE_MASK;
+}
UINT32
GetSystemMemorySizeBelow4gb (
@@ -105,6 +144,19 @@ GetSystemMemorySizeBelow4gb (
UINT8 Cmos0x34;
UINT8 Cmos0x35;
+ //
+ // In PVH case, there is no CMOS, we have to calculate the memory size
+ // from parsing the E820
+ //
+ if (XenPvhDetected ()) {
+UINT64 HighestAddress;
+
+HighestAddress = GetHighestSystemMemoryAddress (TRUE);
+ASSERT (HighestAddress > 0 && HighestAddress <= BASE_4GB);
+
+return HighestAddress;
+ }
+
//
// CMOS 0x34/0x35 specifies the system memory above 16 MB.
// * CMOS(0x35) is the high byte
@@ -129,6 +181,23 @@ GetSystemMemorySizeAbove4gb (
UINT32 Size;
UINTN CmosIndex;
+ //
+ // In PVH case, there is no CMOS, we have to calculate the memory size
+ // from parsing the E820
+ //
+ if (XenPvhDetected ()) {
+UINT64 HighestAddress;
+
+HighestAddress = GetHighestSystemMemoryAddress (FALSE);
+ASSERT (HighestAddress == 0 || HighestAddress >= BASE_4GB);
+
+if (HighestAddress >= BASE_4GB) {
+ HighestAddress -= BASE_4GB;
+}
+
+return HighestAddress;
+ }
+
//
// CMOS 0x5b-0x5d specifies the system memory above 4G
[edk2-devel] [PATCH v5 17/35] OvmfPkg/XenPlatformPei: Reinit XenHypercallLib
The XenPlatformPei needs to make hypercalls, but the XenHypercallLib was initialised before the HyperPage was ready. Now that XenPlatformPei has initialised the HyperPage, reinitialise the XenHypercallLib. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD Reviewed-by: Laszlo Ersek --- Notes: v3: - new patch split from XenHypercallLib: Enable it in PEIM. - check for Lib initialisation failure. OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 + OvmfPkg/XenPlatformPei/Xen.c | 9 + 2 files changed, 10 insertions(+) diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf index 4d00206d09..0ef77db92c 100644 --- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf +++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf @@ -59,6 +59,7 @@ [LibraryClasses] MtrrLib MemEncryptSevLib PcdLib + XenHypercallLib [Pcd] gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c index b366139a0a..c67f4c9697 100644 --- a/OvmfPkg/XenPlatformPei/Xen.c +++ b/OvmfPkg/XenPlatformPei/Xen.c @@ -26,6 +26,7 @@ #include #include #include +#include #include "Platform.h" #include "Xen.h" @@ -88,6 +89,7 @@ XenConnect ( EFI_XEN_OVMF_INFO *Info; CHAR8 Sig[sizeof (Info->Signature) + 1]; UINT32 *PVHResetVectorData; + RETURN_STATUS Status; AsmCpuid (XenLeaf + 2, , , NULL, NULL); mXenInfo.HyperPages = AllocatePages (TransferPages); @@ -152,6 +154,13 @@ XenConnect ( sizeof(mXenInfo) ); + // + // Initialize the XenHypercall library, now that the XenInfo HOB is + // available + // + Status = XenHypercallLibInit (); + ASSERT_RETURN_ERROR (Status); + return EFI_SUCCESS; } -- Anthony PERARD -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45558): https://edk2.groups.io/g/devel/message/45558 Mute This Topic: https://groups.io/mt/32851706/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v5 31/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
On a Xen PVH guest, none of the existing serial or console interface
works, so we add a new one, based on XenConsoleSerialPortLib, and
implemented via SerialDxe.
That is a simple console implementation that can work on both PVH
guest and HVM guests, even if it is rarely going to be used on HVM.
Have PlatformBootManagerLib look for the new console, when running as a
Xen guest.
Since we use VENDOR_UART_DEVICE_PATH, fix its description and coding
style.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v5:
- fix typos in commit message.
v4:
- instead of creating a new XEN_CONSOLE_DEVICE_PATH, use the existing
VENDOR_UART_DEVICE_PATH. And explain why VENDOR_UART_DEVICE_PATH
changed in the commit message.
v3:
- removed PciSioSerialDxe and IsaSerialDxe from OvmfXen, since they
would not be used, maybe, to check.
- some coding style fix
- not changed: PciSioSerialDxe: even if we add SerialDxe, we still needs
PciSioSerialDxe to have OVMF use the emulated serial port on HVM.
v2:
- Use MdeModulePkg/Universal/SerialDxe instead of something new.
- Have PlatformInitializeConsole() look for it by using the
known-in-advance device path for the xen console in the
PLATFORM_CONSOLE_CONNECT_ENTRY.
OvmfPkg/OvmfXen.dsc | 4 ++
OvmfPkg/OvmfXen.fdf | 1 +
.../PlatformBootManagerLib.inf| 4 ++
.../PlatformBootManagerLib/BdsPlatform.h | 1 +
.../PlatformBootManagerLib/BdsPlatform.c | 3 +-
.../PlatformBootManagerLib/PlatformData.c | 49 +--
6 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 54ac910d8e..e719a168f8 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -586,6 +586,10 @@ [Components]
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+ MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
+
+
SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
+ }
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index fa0830a324..5c1a925d6a 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -312,6 +312,7 @@ [FV.DXEFV]
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+INF MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
INF
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 04d614cd49..f89cce1879 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -61,6 +61,10 @@ [Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
+ gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
+ gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
+ gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity ## CONSUMES
+ gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
[Pcd.IA32, Pcd.X64]
gEfiMdePkgTokenSpaceGuid.PcdFSBClock
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
index 49a072b400..153e215101 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
@@ -165,6 +165,7 @@ typedef struct {
#define CONSOLE_IN BIT1
#define STD_ERROR BIT2
extern PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[];
+extern PLATFORM_CONSOLE_CONNECT_ENTRY gXenPlatformConsole[];
//
// Platform BDS Functions
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 1eba304f09..70df6b841a 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -398,7 +398,8 @@ PlatformBootManagerBeforeConsole (
//
EfiBootManagerDispatchDeferredImages ();
- PlatformInitializeConsole (gPlatformConsole);
+ PlatformInitializeConsole (
+XenDetected() ? gXenPlatformConsole : gPlatformConsole);
PcdStatus = PcdSet16S (PcdPlatformBootTimeOut,
GetFrontPageTimeoutFromQemu ());
ASSERT_RETURN_ERROR (PcdStatus);
diff --git
[edk2-devel] [PATCH v5 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
implementation. It will also be used by XenTimerDxe. Override
PcdFSBClock to match Xen vLAPIC timer frequency.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v3:
- expand commit message body to be standalone
OvmfPkg/OvmfXen.dsc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 22970eda5d..477d8c76a1 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -439,6 +439,9 @@ [PcdsFixedAtBuild]
# Point to the MdeModulePkg/Application/UiApp/UiApp.inf
gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c,
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
+ ## Xen vlapic's frequence is 100 MHz
+ gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
+
#
# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#45556): https://edk2.groups.io/g/devel/message/45556
Mute This Topic: https://groups.io/mt/32851704/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v5 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
XenPvhDetected() can be used to figure out if OVMF has started via the
Xen PVH entry point.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v5:
- in XenPvhDetected, check mXenInfo.HyperPages instead of .VersionMajor
OvmfPkg/XenPlatformPei/Platform.h | 5 +
OvmfPkg/XenPlatformPei/Xen.c | 13 +
2 files changed, 18 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
b/OvmfPkg/XenPlatformPei/Platform.h
index 4a80057bdc..db9a62572f 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -99,6 +99,11 @@ XenHvmloaderDetected (
VOID
);
+BOOLEAN
+XenPvhDetected (
+ VOID
+ );
+
VOID
AmdSevInitialize (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 29b42b746c..f26f0e56dd 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -214,6 +214,19 @@ XenHvmloaderDetected (
return (mXenHvmloaderInfo != NULL);
}
+BOOLEAN
+XenPvhDetected (
+ VOID
+ )
+{
+ //
+ // This function should only be used after XenConnect
+ //
+ ASSERT (mXenInfo.HyperPages != NULL);
+
+ return mXenHvmloaderInfo == NULL;
+}
+
VOID
XenPublishRamRegions (
VOID
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#45560): https://edk2.groups.io/g/devel/message/45560
Mute This Topic: https://groups.io/mt/32851708/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v5 21/35] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h
The informations to make a XENMEM_memory_map hypercall is copied over
from the public header of the Xen Project, with the type name modified
to build on OVMF.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v3:
- expanded the "This" that was starting the commit message body.
OvmfPkg/Include/IndustryStandard/Xen/memory.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/memory.h
b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
index 81e981331a..4a33a26d4e 100644
--- a/OvmfPkg/Include/IndustryStandard/Xen/memory.h
+++ b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
@@ -65,6 +65,29 @@ struct xen_remove_from_physmap {
typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+/*
+ * Returns the pseudo-physical memory map as it was when the domain
+ * was started (specified by XENMEM_set_memory_map).
+ * arg == addr of xen_memory_map_t.
+ */
+#define XENMEM_memory_map 9
+struct xen_memory_map {
+/*
+ * On call the number of entries which can be stored in buffer. On
+ * return the number of entries which have been stored in
+ * buffer.
+ */
+UINT32 nr_entries;
+
+/*
+ * Entries in the buffer are in the same format as returned by the
+ * BIOS INT 0x15 EAX=0xE820 call.
+ */
+XEN_GUEST_HANDLE(void) buffer;
+};
+typedef struct xen_memory_map xen_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_memory_map_t);
+
#endif /* __XEN_PUBLIC_MEMORY_H__ */
/*
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#45554): https://edk2.groups.io/g/devel/message/45554
Mute This Topic: https://groups.io/mt/32851702/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v5 19/35] OvmfPkg/XenPlatformPei: Setup HyperPages earlier
We are going to need to make an hypercall in order to retreive the E820
table from the hypervisor before been able to setup the memory.
Calling XenConnect earlier will allow to setup the XenHypercallLib
earlier to allow to make hypercalls.
While here, add some comments in XenConnect().
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
OvmfPkg/XenPlatformPei/Platform.h | 5 +
OvmfPkg/XenPlatformPei/Platform.c | 2 ++
OvmfPkg/XenPlatformPei/Xen.c | 23 ---
3 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
b/OvmfPkg/XenPlatformPei/Platform.h
index 925df31f88..4a80057bdc 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -79,6 +79,11 @@ InstallClearCacheCallback (
VOID
);
+EFI_STATUS
+XenConnect (
+ VOID
+ );
+
EFI_STATUS
InitializeXen (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Platform.c
b/OvmfPkg/XenPlatformPei/Platform.c
index 5809eadb0b..6aaafc3ee9 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -416,6 +416,8 @@ InitializeXenPlatform (
CpuDeadLoop ();
}
+ XenConnect ();
+
BootModeInitialization ();
AddressWidthInitialization ();
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 2105304c41..29b42b746c 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -72,14 +72,11 @@ XenGetE820Map (
/**
Connects to the Hypervisor.
- @param XenLeaf CPUID index used to connect.
-
@return EFI_STATUS
**/
EFI_STATUS
XenConnect (
- UINT32 XenLeaf
)
{
UINT32 Index;
@@ -91,7 +88,13 @@ XenConnect (
UINT32 *PVHResetVectorData;
RETURN_STATUS Status;
- AsmCpuid (XenLeaf + 2, , , NULL, NULL);
+ ASSERT (mXenLeaf != 0);
+
+ //
+ // Prepare HyperPages to be able to make hypercalls
+ //
+
+ AsmCpuid (mXenLeaf + 2, , , NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
if (!mXenInfo.HyperPages) {
return EFI_OUT_OF_RESOURCES;
@@ -103,7 +106,11 @@ XenConnect (
(Index << EFI_PAGE_SHIFT) + Index);
}
- AsmCpuid (XenLeaf + 1, , NULL, NULL, NULL);
+ //
+ // Find out the Xen version
+ //
+
+ AsmCpuid (mXenLeaf + 1, , NULL, NULL, NULL);
DEBUG ((DEBUG_ERROR, "Detected Xen version %d.%d\n",
XenVersion >> 16, XenVersion & 0x));
mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
@@ -262,12 +269,6 @@ InitializeXen (
{
RETURN_STATUS PcdStatus;
- if (mXenLeaf == 0) {
-return EFI_NOT_FOUND;
- }
-
- XenConnect (mXenLeaf);
-
//
// Reserve away HVMLOADER reserved memory [0xFC00,0xFD00).
// This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#4): https://edk2.groups.io/g/devel/message/4
Mute This Topic: https://groups.io/mt/32851703/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v5 15/35] OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist
If the firmware have been started via the Xen PVH entry point, a RSDP
pointer would have been provided. Use it.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v4:
- fix coding style
v3:
- patch splited from the previous one
- Fix DEBUG format string, use %p for pointers.
and use gEfiCallerBaseName to print module name
OvmfPkg/AcpiPlatformDxe/Xen.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
index 82794b933e..f80dfe1a57 100644
--- a/OvmfPkg/AcpiPlatformDxe/Xen.c
+++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
@@ -36,10 +36,27 @@ GetXenAcpiRsdp (
EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *RsdpStructurePtr;
UINT8 *XenAcpiPtr;
UINT8 Sum;
+ EFI_XEN_INFO *XenInfo;
//
// Detect the RSDP structure
//
+
+ //
+ // First look for PVH one
+ //
+ XenInfo = XenGetInfoHOB ();
+ ASSERT (XenInfo != NULL);
+ if (XenInfo->RsdpPvh != NULL) {
+DEBUG ((DEBUG_INFO, "%a: Use ACPI RSDP table at 0x%p\n",
+ gEfiCallerBaseName, XenInfo->RsdpPvh));
+*RsdpPtr = XenInfo->RsdpPvh;
+return EFI_SUCCESS;
+ }
+
+ //
+ // Otherwise, look for the HVM one
+ //
for (XenAcpiPtr = (UINT8*)(UINTN) XEN_ACPI_PHYSICAL_ADDRESS;
XenAcpiPtr < (UINT8*)(UINTN) XEN_BIOS_PHYSICAL_END;
XenAcpiPtr += 0x10) {
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#45537): https://edk2.groups.io/g/devel/message/45537
Mute This Topic: https://groups.io/mt/32851681/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v5 18/35] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected
This new XenHvmloaderDetected() return true if the hvmloader firmware
has runned before OVMF.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v3:
- Added one sentence in the commit message.
OvmfPkg/XenPlatformPei/Platform.h | 5 +
OvmfPkg/XenPlatformPei/Xen.c | 7 +++
2 files changed, 12 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
b/OvmfPkg/XenPlatformPei/Platform.h
index 77427496c0..925df31f88 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -89,6 +89,11 @@ XenDetect (
VOID
);
+BOOLEAN
+XenHvmloaderDetected (
+ VOID
+ );
+
VOID
AmdSevInitialize (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index c67f4c9697..2105304c41 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -199,6 +199,13 @@ XenDetect (
return FALSE;
}
+BOOLEAN
+XenHvmloaderDetected (
+ VOID
+ )
+{
+ return (mXenHvmloaderInfo != NULL);
+}
VOID
XenPublishRamRegions (
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#45541): https://edk2.groups.io/g/devel/message/45541
Mute This Topic: https://groups.io/mt/32851685/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
