* [Xen-devel] [PATCH v2 00/31] Specific platform to run OVMF in Xen PVH and HVM guests
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Resent, to send to the new edk2 ML.
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v2
Hi,
I've created a Xen specific platform, in OvmfPkg/XenOvmf.dsc
with the goal to make it work on both Xen HVM and Xen PVH.
https://bugzilla.tianocore.org/show_bug.cgi?id=1689
The first few patches only create the platform and duplicate some code from
OvmfPkg and the later patches makes OVMF boot in a Xen PVH guest and can boot
a Linux guest.
After this patch series, I'd like to wait a bit before removing Xen support
from the OvmfPkg*.dsc, to allow time to switch to the new Xen only platform,
maybe 1 year.
To build and boot:
To build, simply run OvmfPkg/build.sh -p OvmfPkg/XenOvmf.dsc
Then use OVMF.fd as a kernel of a pvh guest config file (with xl/libxl).
Anthony PERARD (31):
OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
OvmfPkg: Create platform XenOvmf
OvmfPkg: Introduce XenResetVector
OvmfPkg: Introduce XenPlatformPei
OvmfPkg/XenOvmf: Creating an ELF header
OvmfPkg/XenResetVector: Add new entry point for Xen PVH
OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests
OvmfPkg/XenResetVector: Allow to jumpstart from either hvmloader or
PVH
OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU
OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820
OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
OvmfPkg/Library/XenPlatformLib: New library
OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist
OvmfPkg/XenHypercallLib: Enable it in PEIM
OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected
OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it as
runned
OvmfPkg/XenPlatformPei: Setup HyperPages earlier
OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h
OvmfPkg/XenPlatformPei: Get E820 table via hypercall ...
OvmfPkg/XenPlatformPei: Rework memory detection
OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux
OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen
PVH
OvmfPkg/XenOvmf: Override PcdFSBClock to Xen vLAPIC timer frequency
OvmfPkg/XenOvmf: Introduce XenTimerDxe
OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg
OvmfPkg/OvmfPkg.dec | 4 +
ArmVirtPkg/ArmVirtXen.dsc | 2 +-
OvmfPkg/OvmfPkgIa32.dsc | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
OvmfPkg/OvmfPkgX64.dsc | 1 +
OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 236 ++------
OvmfPkg/XenOvmf.fdf | 561 ++++++++++++++++++++
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 +-
OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 4 +
OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 +
OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf | 2 +-
ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf => OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf | 30 +-
{ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf | 0
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf | 35 ++
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 107 ++++
OvmfPkg/XenResetVector/XenResetVector.inf | 46 ++
OvmfPkg/XenTimerDxe/XenTimerDxe.inf | 49 ++
OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h | 6 +-
OvmfPkg/Include/Guid/XenInfo.h | 8 +-
OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h | 159 ++++++
OvmfPkg/Include/IndustryStandard/Xen/memory.h | 23 +
OvmfPkg/Include/Library/XenHypercallLib.h | 12 +
OvmfPkg/Include/Library/XenPlatformLib.h | 59 ++
OvmfPkg/Include/OvmfPlatforms.h | 6 +
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h | 1 +
OvmfPkg/XenPlatformPei/Cmos.h | 58 ++
OvmfPkg/XenPlatformPei/Platform.h | 135 +++++
OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.h | 0
OvmfPkg/XenTimerDxe/XenTimerDxe.h | 183 +++++++
OvmfPkg/AcpiPlatformDxe/Xen.c | 41 +-
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 15 +-
OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c | 59 ++
OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c | 3 +-
OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c | 11 +
OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c | 75 +++
{ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c | 0
OvmfPkg/PlatformPei/Xen.c | 3 -
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 38 ++
OvmfPkg/XenPlatformPei/AmdSev.c | 70 +++
OvmfPkg/XenPlatformPei/ClearCache.c | 118 ++++
OvmfPkg/XenPlatformPei/Cmos.c | 66 +++
OvmfPkg/XenPlatformPei/Fv.c | 82 +++
OvmfPkg/XenPlatformPei/MemDetect.c | 498 +++++++++++++++++
OvmfPkg/XenPlatformPei/Platform.c | 458 ++++++++++++++++
OvmfPkg/XenPlatformPei/Xen.c | 381 +++++++++++++
OvmfPkg/XenTimerDxe/XenTimerDxe.c | 361 +++++++++++++
generate_elf_header.c | 78 +++
OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm | 144 +++++
OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm | 87 +++
OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm | 66 +++
OvmfPkg/XenResetVector/Ia32/PageTables64.asm | 156 ++++++
OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm | 93 ++++
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 75 +++
OvmfPkg/XenResetVector/XenResetVector.nasmb | 78 +++
54 files changed, 4526 insertions(+), 262 deletions(-)
copy OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} (78%)
create mode 100644 OvmfPkg/XenOvmf.fdf
copy ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf => OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf (50%)
rename {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf (100%)
create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
create mode 100644 OvmfPkg/XenPlatformPei/XenPlatformPei.inf
create mode 100644 OvmfPkg/XenResetVector/XenResetVector.inf
create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.inf
create mode 100644 OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
create mode 100644 OvmfPkg/Include/Library/XenPlatformLib.h
create mode 100644 OvmfPkg/XenPlatformPei/Cmos.h
create mode 100644 OvmfPkg/XenPlatformPei/Platform.h
copy OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.h (100%)
create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.h
create mode 100644 OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
rename {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c (100%)
create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
create mode 100644 OvmfPkg/XenPlatformPei/AmdSev.c
create mode 100644 OvmfPkg/XenPlatformPei/ClearCache.c
create mode 100644 OvmfPkg/XenPlatformPei/Cmos.c
create mode 100644 OvmfPkg/XenPlatformPei/Fv.c
create mode 100644 OvmfPkg/XenPlatformPei/MemDetect.c
create mode 100644 OvmfPkg/XenPlatformPei/Platform.c
create mode 100644 OvmfPkg/XenPlatformPei/Xen.c
create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.c
create mode 100644 generate_elf_header.c
create mode 100644 OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
create mode 100644 OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
create mode 100644 OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
create mode 100644 OvmfPkg/XenResetVector/Ia32/PageTables64.asm
create mode 100644 OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
create mode 100644 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
create mode 100644 OvmfPkg/XenResetVector/XenResetVector.nasmb
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH v2 01/31] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
and remove extra includes of OvmfPlatforms.h.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
v2:
- also add PciLib.h include to the .c
- and remove extra include of OvmfPlatforms.h
OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 +
OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c | 3 +--
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
index 39ca805730..ebd722e66b 100644
--- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
+++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
@@ -36,4 +36,5 @@ [Packages]
[LibraryClasses]
DebugLib
IoLib
+ PciLib
TimerLib
diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
index cc75d046a8..9348502836 100644
--- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
+++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
@@ -17,11 +17,10 @@
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
#include <Library/IoLib.h>
+#include <Library/PciLib.h>
#include <Library/TimerLib.h>
#include <OvmfPlatforms.h>
-#include <OvmfPlatforms.h>
-
VOID
AcpiPmControl (
UINTN SuspendType
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 01/31] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
and remove extra includes of OvmfPlatforms.h.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
v2:
- also add PciLib.h include to the .c
- and remove extra include of OvmfPlatforms.h
OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 +
OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c | 3 +--
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
index 39ca805730..ebd722e66b 100644
--- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
+++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
@@ -36,4 +36,5 @@ [Packages]
[LibraryClasses]
DebugLib
IoLib
+ PciLib
TimerLib
diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
index cc75d046a8..9348502836 100644
--- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
+++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
@@ -17,11 +17,10 @@
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
#include <Library/IoLib.h>
+#include <Library/PciLib.h>
#include <Library/TimerLib.h>
#include <OvmfPlatforms.h>
-#include <OvmfPlatforms.h>
-
VOID
AcpiPmControl (
UINTN SuspendType
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 01/31] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
@ 2019-04-10 8:48 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-10 8:48 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> and remove extra includes of OvmfPlatforms.h.
(1) In commit messages, please don't rely on the subject line, and the
first paragraph of the body, being read as a single sentence.
(Similarly, please avoid empy commit message bodies.) If there's no
better way to prevent this, then just repeat the subject line in te
first paragraph.
I realize this is subjective & project dependent; it's certainly my
preference, but I recall other reviewers requesting the same on edk2-devel.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
(2) Please drop this line from all the commit messages:
<https://bugzilla.tianocore.org/show_bug.cgi?id=1655#c0>.
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> v2:
> - also add PciLib.h include to the .c
> - and remove extra include of OvmfPlatforms.h
>
> OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 +
> OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c | 3 +--
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
> index 39ca805730..ebd722e66b 100644
> --- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
> +++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
> @@ -36,4 +36,5 @@ [Packages]
> [LibraryClasses]
> DebugLib
> IoLib
> + PciLib
> TimerLib
> diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
> index cc75d046a8..9348502836 100644
> --- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
> +++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
> @@ -17,11 +17,10 @@
> #include <Library/BaseLib.h>
> #include <Library/DebugLib.h>
> #include <Library/IoLib.h>
> +#include <Library/PciLib.h>
> #include <Library/TimerLib.h>
> #include <OvmfPlatforms.h>
>
> -#include <OvmfPlatforms.h>
> -
> VOID
> AcpiPmControl (
> UINTN SuspendType
>
Hm, the duplicated #include is my fault, from commit 1466b76f9385
("OvmfPkg: determine PMBA value dependent on host bridge device ID",
2016-05-17). Thanks for fixing that up.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 01/31] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
@ 2019-04-10 8:48 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-10 8:48 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> and remove extra includes of OvmfPlatforms.h.
(1) In commit messages, please don't rely on the subject line, and the
first paragraph of the body, being read as a single sentence.
(Similarly, please avoid empy commit message bodies.) If there's no
better way to prevent this, then just repeat the subject line in te
first paragraph.
I realize this is subjective & project dependent; it's certainly my
preference, but I recall other reviewers requesting the same on edk2-devel.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
(2) Please drop this line from all the commit messages:
<https://bugzilla.tianocore.org/show_bug.cgi?id=1655#c0>.
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> v2:
> - also add PciLib.h include to the .c
> - and remove extra include of OvmfPlatforms.h
>
> OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 +
> OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c | 3 +--
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
> index 39ca805730..ebd722e66b 100644
> --- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
> +++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
> @@ -36,4 +36,5 @@ [Packages]
> [LibraryClasses]
> DebugLib
> IoLib
> + PciLib
> TimerLib
> diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
> index cc75d046a8..9348502836 100644
> --- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
> +++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
> @@ -17,11 +17,10 @@
> #include <Library/BaseLib.h>
> #include <Library/DebugLib.h>
> #include <Library/IoLib.h>
> +#include <Library/PciLib.h>
> #include <Library/TimerLib.h>
> #include <OvmfPlatforms.h>
>
> -#include <OvmfPlatforms.h>
> -
> VOID
> AcpiPmControl (
> UINTN SuspendType
>
Hm, the duplicated #include is my fault, from commit 1466b76f9385
("OvmfPkg: determine PMBA value dependent on host bridge device ID",
2016-05-17). Thanks for fixing that up.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 01/31] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
@ 2019-04-10 9:16 ` Jordan Justen
0 siblings, 0 replies; 168+ messages in thread
From: Jordan Justen @ 2019-04-10 9:16 UTC (permalink / raw)
To: Laszlo Ersek, anthony.perard, devel
Cc: xen-devel, Julien Grall, Ard Biesheuvel
On 2019-04-10 01:48:39, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
> > and remove extra includes of OvmfPlatforms.h.
>
> (1) In commit messages, please don't rely on the subject line, and the
> first paragraph of the body, being read as a single sentence.
I think BaseTools/Scripts/PatchCheck.py does try to check that the
second line of the commit message is an empty line.
Also,
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
-Jordan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v2 01/31] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
@ 2019-04-10 9:16 ` Jordan Justen
0 siblings, 0 replies; 168+ messages in thread
From: Jordan Justen @ 2019-04-10 9:16 UTC (permalink / raw)
To: Laszlo Ersek, anthony.perard, devel
Cc: xen-devel, Julien Grall, Ard Biesheuvel
On 2019-04-10 01:48:39, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
> > and remove extra includes of OvmfPlatforms.h.
>
> (1) In commit messages, please don't rely on the subject line, and the
> first paragraph of the body, being read as a single sentence.
I think BaseTools/Scripts/PatchCheck.py does try to check that the
second line of the commit message is an empty line.
Also,
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
-Jordan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This is a copy of OvmfX64, removing VirtIO and some SMM.
This new platform will be changed to make it works on two types of Xen
guest: HVM and PVH.
Compare to OvmfX64, this patch:
- changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
- removed: VirtioLib class resolution
- removed: all UEFI_DRIVER modules for virtio devices
- removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
- removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
- removed: Everything related to SMM_REQUIRE==true
- removed: Everything related to SECURE_BOOT_ENABLE==true
- removed: Everything related to TPM2_ENABLE==true
- changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
- changed: default FD_SIZE_IN_KB to 2M.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
OvmfPkg/{OvmfPkgIa32X64.fdf => XenOvmf.fdf} | 72 +------
2 files changed, 12 insertions(+), 262 deletions(-)
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/XenOvmf.dsc
similarity index 79%
copy from OvmfPkg/OvmfPkgX64.dsc
copy to OvmfPkg/XenOvmf.dsc
index 2943e9e8af..bfe9190735 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -3,6 +3,7 @@
#
# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -21,26 +22,22 @@
################################################################################
[Defines]
PLATFORM_NAME = Ovmf
- PLATFORM_GUID = 5a9e7754-d81b-49ea-85ad-69eaa7b1539b
+ PLATFORM_GUID = e3aa4fbe-9459-482d-bd40-d3f3b5f89d6e
PLATFORM_VERSION = 0.1
DSC_SPECIFICATION = 0x00010005
- OUTPUT_DIRECTORY = Build/OvmfX64
+ OUTPUT_DIRECTORY = Build/XenOvmf
SUPPORTED_ARCHITECTURES = X64
BUILD_TARGETS = NOOPT|DEBUG|RELEASE
SKUID_IDENTIFIER = DEFAULT
- FLASH_DEFINITION = OvmfPkg/OvmfPkgX64.fdf
+ FLASH_DEFINITION = OvmfPkg/XenOvmf.fdf
#
# Defines for default states. These can be changed on the command line.
# -D FLAG=VALUE
#
- DEFINE SECURE_BOOT_ENABLE = FALSE
DEFINE NETWORK_IP6_ENABLE = FALSE
DEFINE HTTP_BOOT_ENABLE = FALSE
- DEFINE SMM_REQUIRE = FALSE
DEFINE TLS_ENABLE = FALSE
- DEFINE TPM2_ENABLE = FALSE
- DEFINE TPM2_CONFIG_ENABLE = FALSE
DEFINE USE_LEGACY_ISA_STACK = FALSE
#
@@ -57,7 +54,7 @@ [Defines]
!ifdef $(FD_SIZE_4MB)
DEFINE FD_SIZE_IN_KB = 4096
!else
- DEFINE FD_SIZE_IN_KB = 4096
+ DEFINE FD_SIZE_IN_KB = 2048
!endif
!endif
!endif
@@ -157,12 +154,9 @@ [LibraryClasses]
UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
SerializeVariablesLib|OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.inf
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxeLib.inf
- VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
-!if $(SMM_REQUIRE) == FALSE
LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
-!endif
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
@@ -185,14 +179,8 @@ [LibraryClasses]
OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
!endif
-!if $(SECURE_BOOT_ENABLE) == TRUE
- PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
- TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
- AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
-!else
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
-!endif
VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
@@ -211,13 +199,7 @@ [LibraryClasses]
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
-!if $(TPM2_ENABLE) == TRUE
- Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
- Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
- Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
-!else
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
-!endif
[LibraryClasses.common]
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -283,11 +265,6 @@ [LibraryClasses.common.PEIM]
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf
-!if $(TPM2_ENABLE) == TRUE
- BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
- Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
-!endif
-
[LibraryClasses.common.DXE_CORE]
HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
@@ -357,20 +334,13 @@ [LibraryClasses.common.DXE_DRIVER]
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
-!if $(SMM_REQUIRE) == TRUE
- LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
-!else
LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
-!endif
!ifdef $(SOURCE_DEBUG_ENABLE)
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
!endif
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
-!if $(TPM2_ENABLE) == TRUE
- Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
-!endif
[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -385,43 +355,6 @@ [LibraryClasses.common.UEFI_APPLICATION]
!endif
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
-[LibraryClasses.common.DXE_SMM_DRIVER]
- PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
- MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
- ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
- HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
- SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
- MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
- SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
-!ifdef $(DEBUG_ON_SERIAL_PORT)
- DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
-!else
- DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
-!endif
- CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
-!ifdef $(SOURCE_DEBUG_ENABLE)
- DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
-!endif
- BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
- PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
-
-[LibraryClasses.common.SMM_CORE]
- PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
- SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
- MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
- ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
- HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
- SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
- SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
-!ifdef $(DEBUG_ON_SERIAL_PORT)
- DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
-!else
- DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
-!endif
- PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
-
################################################################################
#
# Pcd Section - list of all EDK II PCD Entries defined by this Platform.
@@ -436,10 +369,6 @@ [PcdsFeatureFlag]
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
-!if $(SMM_REQUIRE) == TRUE
- gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
- gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
-!endif
[PcdsFixedAtBuild]
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
@@ -516,10 +445,6 @@ [PcdsFixedAtBuild]
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
-!if $(SMM_REQUIRE) == TRUE
- gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
-!endif
-
# IRQs 5, 9, 10, 11 are level-triggered
gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
@@ -533,14 +458,11 @@ [PcdsFixedAtBuild]
################################################################################
[PcdsDynamicDefault]
- # only set when
- # ($(SMM_REQUIRE) == FALSE)
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
-
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
- gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|TRUE
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable|FALSE
@@ -573,18 +495,8 @@ [PcdsDynamicDefault]
# Set memory encryption mask
gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
-!if $(SMM_REQUIRE) == TRUE
- gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
- gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
- gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000
-!endif
-
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
-!if $(TPM2_ENABLE) == TRUE
- gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
-!endif
-
################################################################################
#
# Components Section - list of all EDK II Modules needed by this Platform.
@@ -620,32 +532,9 @@ [Components]
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
OvmfPkg/PlatformPei/PlatformPei.inf
- UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
- <LibraryClasses>
-!if $(SMM_REQUIRE) == TRUE
- LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
-!endif
- }
-!if $(SMM_REQUIRE) == TRUE
- OvmfPkg/SmmAccess/SmmAccessPei.inf
-!endif
+ UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
UefiCpuPkg/CpuMpPei/CpuMpPei.inf
-!if $(TPM2_ENABLE) == TRUE
- OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
- SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf {
- <LibraryClasses>
- HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
- }
-!if $(TPM2_CONFIG_ENABLE) == TRUE
- SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
-!endif
-!endif
-
#
# DXE Phase modules
#
@@ -664,15 +553,7 @@ [Components]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
- MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
- <LibraryClasses>
-!if $(SECURE_BOOT_ENABLE) == TRUE
- NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
-!endif
-!if $(TPM2_ENABLE) == TRUE
- NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf
-!endif
- }
+ MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
@@ -712,11 +593,6 @@ [Components]
NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
!endif
}
- OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
- OvmfPkg/Virtio10Dxe/Virtio10.inf
- OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
- OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
- OvmfPkg/VirtioRngDxe/VirtioRng.inf
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
@@ -755,7 +631,6 @@ [Components]
OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
- OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
#
# ISA Support
@@ -824,7 +699,6 @@ [Components]
NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
}
!endif
- OvmfPkg/VirtioNetDxe/VirtioNet.inf
#
# Usb Support
@@ -874,56 +748,10 @@ [Components]
gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
}
-!if $(SECURE_BOOT_ENABLE) == TRUE
- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-!endif
-
OvmfPkg/PlatformDxe/Platform.inf
OvmfPkg/AmdSevDxe/AmdSevDxe.inf
OvmfPkg/IoMmuDxe/IoMmuDxe.inf
-!if $(SMM_REQUIRE) == TRUE
- OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
- OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
- UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
-
- #
- # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
- #
- MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
-
- #
- # SMM_CORE
- #
- MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
-
- #
- # Privileged drivers (DXE_SMM_DRIVER modules)
- #
- UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
- MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf {
- <LibraryClasses>
- LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
- }
- UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
- <LibraryClasses>
- SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
- SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
- }
-
- #
- # Variable driver stack (SMM)
- #
- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
- MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
- <LibraryClasses>
- NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
- }
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
-
-!else
-
#
# Variable driver stack (non-SMM)
#
@@ -937,17 +765,3 @@ [Components]
<LibraryClasses>
NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
}
-!endif
-
-!if $(TPM2_ENABLE) == TRUE
- SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf {
- <LibraryClasses>
- Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
- NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf
- HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
- }
-!endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/XenOvmf.fdf
similarity index 85%
copy from OvmfPkg/OvmfPkgIa32X64.fdf
copy to OvmfPkg/XenOvmf.fdf
index 6c40540202..612ffb2e01 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -3,6 +3,7 @@
#
# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -68,10 +69,10 @@ [FD.OVMF_CODE]
[FD.MEMFD]
BaseAddress = $(MEMFD_BASE_ADDRESS)
-Size = 0xC00000
+Size = 0xB00000
ErasePolarity = 1
BlockSize = 0x10000
-NumBlocks = 0xC0
+NumBlocks = 0xB0
0x000000|0x006000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
@@ -89,7 +90,7 @@ [FD.MEMFD]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
FV = PEIFV
-0x100000|0xB00000
+0x100000|0xA00000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
FV = DXEFV
@@ -160,16 +161,8 @@ [FV.PEIFV]
INF OvmfPkg/PlatformPei/PlatformPei.inf
INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
-!if $(SMM_REQUIRE) == TRUE
-INF OvmfPkg/SmmAccess/SmmAccessPei.inf
-!endif
INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
-!if $(TPM2_ENABLE) == TRUE
-INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
-INF SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
-!endif
-
################################################################################
[FV.DXEFV]
@@ -197,9 +190,6 @@ [FV.DXEFV]
INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
-!if $(SMM_REQUIRE) == FALSE
- INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
-!endif
}
#
@@ -226,19 +216,10 @@ [FV.DXEFV]
INF MdeModulePkg/Universal/Metronome/Metronome.inf
INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
-INF OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
-INF OvmfPkg/Virtio10Dxe/Virtio10.inf
-INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
-INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
-INF OvmfPkg/VirtioRngDxe/VirtioRng.inf
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
-!if $(SECURE_BOOT_ENABLE) == TRUE
- INF SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-!endif
-
INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
@@ -337,7 +318,6 @@ [FV.DXEFV]
INF NetworkPkg/TlsDxe/TlsDxe.inf
INF NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
!endif
- INF OvmfPkg/VirtioNetDxe/VirtioNet.inf
#
# Usb Support
@@ -357,31 +337,10 @@ [FV.DXEFV]
INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
-INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
INF OvmfPkg/PlatformDxe/Platform.inf
INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
INF OvmfPkg/IoMmuDxe/IoMmuDxe.inf
-!if $(SMM_REQUIRE) == TRUE
-INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
-INF OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
-INF UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
-INF MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
-INF MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
-INF UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
-INF MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
-INF UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
-
-#
-# Variable driver stack (SMM)
-#
-INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
-INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
-INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
-INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
-
-!else
-
#
# Variable driver stack (non-SMM)
#
@@ -389,14 +348,6 @@ [FV.DXEFV]
INF OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
-!endif
-
-!if $(TPM2_ENABLE) == TRUE
-INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
-!if $(TPM2_CONFIG_ENABLE) == TRUE
-INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
-!endif
-!endif
################################################################################
@@ -527,18 +478,3 @@ [Rule.Common.SEC.RESET_VECTOR]
FILE RAW = $(NAMED_GUID) {
RAW BIN Align = 16 |.bin
}
-
-[Rule.Common.SMM_CORE]
- FILE SMM_CORE = $(NAMED_GUID) {
- PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
- UI STRING="$(MODULE_NAME)" Optional
- VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
- }
-
-[Rule.Common.DXE_SMM_DRIVER]
- FILE SMM = $(NAMED_GUID) {
- SMM_DEPEX SMM_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
- PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
- UI STRING="$(MODULE_NAME)" Optional
- VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
- }
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This is a copy of OvmfX64, removing VirtIO and some SMM.
This new platform will be changed to make it works on two types of Xen
guest: HVM and PVH.
Compare to OvmfX64, this patch:
- changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
- removed: VirtioLib class resolution
- removed: all UEFI_DRIVER modules for virtio devices
- removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
- removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
- removed: Everything related to SMM_REQUIRE==true
- removed: Everything related to SECURE_BOOT_ENABLE==true
- removed: Everything related to TPM2_ENABLE==true
- changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
- changed: default FD_SIZE_IN_KB to 2M.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
OvmfPkg/{OvmfPkgIa32X64.fdf => XenOvmf.fdf} | 72 +------
2 files changed, 12 insertions(+), 262 deletions(-)
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/XenOvmf.dsc
similarity index 79%
copy from OvmfPkg/OvmfPkgX64.dsc
copy to OvmfPkg/XenOvmf.dsc
index 2943e9e8af..bfe9190735 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -3,6 +3,7 @@
#
# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -21,26 +22,22 @@
################################################################################
[Defines]
PLATFORM_NAME = Ovmf
- PLATFORM_GUID = 5a9e7754-d81b-49ea-85ad-69eaa7b1539b
+ PLATFORM_GUID = e3aa4fbe-9459-482d-bd40-d3f3b5f89d6e
PLATFORM_VERSION = 0.1
DSC_SPECIFICATION = 0x00010005
- OUTPUT_DIRECTORY = Build/OvmfX64
+ OUTPUT_DIRECTORY = Build/XenOvmf
SUPPORTED_ARCHITECTURES = X64
BUILD_TARGETS = NOOPT|DEBUG|RELEASE
SKUID_IDENTIFIER = DEFAULT
- FLASH_DEFINITION = OvmfPkg/OvmfPkgX64.fdf
+ FLASH_DEFINITION = OvmfPkg/XenOvmf.fdf
#
# Defines for default states. These can be changed on the command line.
# -D FLAG=VALUE
#
- DEFINE SECURE_BOOT_ENABLE = FALSE
DEFINE NETWORK_IP6_ENABLE = FALSE
DEFINE HTTP_BOOT_ENABLE = FALSE
- DEFINE SMM_REQUIRE = FALSE
DEFINE TLS_ENABLE = FALSE
- DEFINE TPM2_ENABLE = FALSE
- DEFINE TPM2_CONFIG_ENABLE = FALSE
DEFINE USE_LEGACY_ISA_STACK = FALSE
#
@@ -57,7 +54,7 @@ [Defines]
!ifdef $(FD_SIZE_4MB)
DEFINE FD_SIZE_IN_KB = 4096
!else
- DEFINE FD_SIZE_IN_KB = 4096
+ DEFINE FD_SIZE_IN_KB = 2048
!endif
!endif
!endif
@@ -157,12 +154,9 @@ [LibraryClasses]
UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
SerializeVariablesLib|OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.inf
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxeLib.inf
- VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
-!if $(SMM_REQUIRE) == FALSE
LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
-!endif
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
@@ -185,14 +179,8 @@ [LibraryClasses]
OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
!endif
-!if $(SECURE_BOOT_ENABLE) == TRUE
- PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
- TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
- AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
-!else
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
-!endif
VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
@@ -211,13 +199,7 @@ [LibraryClasses]
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
-!if $(TPM2_ENABLE) == TRUE
- Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
- Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
- Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
-!else
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
-!endif
[LibraryClasses.common]
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -283,11 +265,6 @@ [LibraryClasses.common.PEIM]
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf
-!if $(TPM2_ENABLE) == TRUE
- BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
- Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
-!endif
-
[LibraryClasses.common.DXE_CORE]
HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
@@ -357,20 +334,13 @@ [LibraryClasses.common.DXE_DRIVER]
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
-!if $(SMM_REQUIRE) == TRUE
- LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
-!else
LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
-!endif
!ifdef $(SOURCE_DEBUG_ENABLE)
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
!endif
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
-!if $(TPM2_ENABLE) == TRUE
- Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
-!endif
[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -385,43 +355,6 @@ [LibraryClasses.common.UEFI_APPLICATION]
!endif
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
-[LibraryClasses.common.DXE_SMM_DRIVER]
- PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
- MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
- ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
- HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
- SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
- MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
- SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
-!ifdef $(DEBUG_ON_SERIAL_PORT)
- DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
-!else
- DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
-!endif
- CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
-!ifdef $(SOURCE_DEBUG_ENABLE)
- DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
-!endif
- BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
- PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
-
-[LibraryClasses.common.SMM_CORE]
- PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
- SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
- MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
- ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
- HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
- SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
- SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
-!ifdef $(DEBUG_ON_SERIAL_PORT)
- DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
-!else
- DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
-!endif
- PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
-
################################################################################
#
# Pcd Section - list of all EDK II PCD Entries defined by this Platform.
@@ -436,10 +369,6 @@ [PcdsFeatureFlag]
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
-!if $(SMM_REQUIRE) == TRUE
- gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
- gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
-!endif
[PcdsFixedAtBuild]
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
@@ -516,10 +445,6 @@ [PcdsFixedAtBuild]
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
-!if $(SMM_REQUIRE) == TRUE
- gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
-!endif
-
# IRQs 5, 9, 10, 11 are level-triggered
gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
@@ -533,14 +458,11 @@ [PcdsFixedAtBuild]
################################################################################
[PcdsDynamicDefault]
- # only set when
- # ($(SMM_REQUIRE) == FALSE)
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
-
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
- gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|TRUE
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable|FALSE
@@ -573,18 +495,8 @@ [PcdsDynamicDefault]
# Set memory encryption mask
gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
-!if $(SMM_REQUIRE) == TRUE
- gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
- gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
- gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000
-!endif
-
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
-!if $(TPM2_ENABLE) == TRUE
- gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
-!endif
-
################################################################################
#
# Components Section - list of all EDK II Modules needed by this Platform.
@@ -620,32 +532,9 @@ [Components]
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
OvmfPkg/PlatformPei/PlatformPei.inf
- UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
- <LibraryClasses>
-!if $(SMM_REQUIRE) == TRUE
- LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
-!endif
- }
-!if $(SMM_REQUIRE) == TRUE
- OvmfPkg/SmmAccess/SmmAccessPei.inf
-!endif
+ UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
UefiCpuPkg/CpuMpPei/CpuMpPei.inf
-!if $(TPM2_ENABLE) == TRUE
- OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
- SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf {
- <LibraryClasses>
- HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
- }
-!if $(TPM2_CONFIG_ENABLE) == TRUE
- SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
-!endif
-!endif
-
#
# DXE Phase modules
#
@@ -664,15 +553,7 @@ [Components]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
- MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
- <LibraryClasses>
-!if $(SECURE_BOOT_ENABLE) == TRUE
- NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
-!endif
-!if $(TPM2_ENABLE) == TRUE
- NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf
-!endif
- }
+ MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
@@ -712,11 +593,6 @@ [Components]
NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
!endif
}
- OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
- OvmfPkg/Virtio10Dxe/Virtio10.inf
- OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
- OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
- OvmfPkg/VirtioRngDxe/VirtioRng.inf
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
@@ -755,7 +631,6 @@ [Components]
OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
- OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
#
# ISA Support
@@ -824,7 +699,6 @@ [Components]
NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
}
!endif
- OvmfPkg/VirtioNetDxe/VirtioNet.inf
#
# Usb Support
@@ -874,56 +748,10 @@ [Components]
gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
}
-!if $(SECURE_BOOT_ENABLE) == TRUE
- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-!endif
-
OvmfPkg/PlatformDxe/Platform.inf
OvmfPkg/AmdSevDxe/AmdSevDxe.inf
OvmfPkg/IoMmuDxe/IoMmuDxe.inf
-!if $(SMM_REQUIRE) == TRUE
- OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
- OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
- UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
-
- #
- # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
- #
- MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
-
- #
- # SMM_CORE
- #
- MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
-
- #
- # Privileged drivers (DXE_SMM_DRIVER modules)
- #
- UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
- MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf {
- <LibraryClasses>
- LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
- }
- UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
- <LibraryClasses>
- SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
- SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
- }
-
- #
- # Variable driver stack (SMM)
- #
- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
- MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
- <LibraryClasses>
- NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
- }
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
-
-!else
-
#
# Variable driver stack (non-SMM)
#
@@ -937,17 +765,3 @@ [Components]
<LibraryClasses>
NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
}
-!endif
-
-!if $(TPM2_ENABLE) == TRUE
- SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf {
- <LibraryClasses>
- Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
- NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf
- HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
- }
-!endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/XenOvmf.fdf
similarity index 85%
copy from OvmfPkg/OvmfPkgIa32X64.fdf
copy to OvmfPkg/XenOvmf.fdf
index 6c40540202..612ffb2e01 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -3,6 +3,7 @@
#
# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -68,10 +69,10 @@ [FD.OVMF_CODE]
[FD.MEMFD]
BaseAddress = $(MEMFD_BASE_ADDRESS)
-Size = 0xC00000
+Size = 0xB00000
ErasePolarity = 1
BlockSize = 0x10000
-NumBlocks = 0xC0
+NumBlocks = 0xB0
0x000000|0x006000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
@@ -89,7 +90,7 @@ [FD.MEMFD]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
FV = PEIFV
-0x100000|0xB00000
+0x100000|0xA00000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
FV = DXEFV
@@ -160,16 +161,8 @@ [FV.PEIFV]
INF OvmfPkg/PlatformPei/PlatformPei.inf
INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
-!if $(SMM_REQUIRE) == TRUE
-INF OvmfPkg/SmmAccess/SmmAccessPei.inf
-!endif
INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
-!if $(TPM2_ENABLE) == TRUE
-INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
-INF SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
-!endif
-
################################################################################
[FV.DXEFV]
@@ -197,9 +190,6 @@ [FV.DXEFV]
INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
-!if $(SMM_REQUIRE) == FALSE
- INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
-!endif
}
#
@@ -226,19 +216,10 @@ [FV.DXEFV]
INF MdeModulePkg/Universal/Metronome/Metronome.inf
INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
-INF OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
-INF OvmfPkg/Virtio10Dxe/Virtio10.inf
-INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
-INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
-INF OvmfPkg/VirtioRngDxe/VirtioRng.inf
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
-!if $(SECURE_BOOT_ENABLE) == TRUE
- INF SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-!endif
-
INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
@@ -337,7 +318,6 @@ [FV.DXEFV]
INF NetworkPkg/TlsDxe/TlsDxe.inf
INF NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
!endif
- INF OvmfPkg/VirtioNetDxe/VirtioNet.inf
#
# Usb Support
@@ -357,31 +337,10 @@ [FV.DXEFV]
INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
-INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
INF OvmfPkg/PlatformDxe/Platform.inf
INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
INF OvmfPkg/IoMmuDxe/IoMmuDxe.inf
-!if $(SMM_REQUIRE) == TRUE
-INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
-INF OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
-INF UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
-INF MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
-INF MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
-INF UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
-INF MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
-INF UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
-
-#
-# Variable driver stack (SMM)
-#
-INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
-INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
-INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
-INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
-
-!else
-
#
# Variable driver stack (non-SMM)
#
@@ -389,14 +348,6 @@ [FV.DXEFV]
INF OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
-!endif
-
-!if $(TPM2_ENABLE) == TRUE
-INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
-!if $(TPM2_CONFIG_ENABLE) == TRUE
-INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
-!endif
-!endif
################################################################################
@@ -527,18 +478,3 @@ [Rule.Common.SEC.RESET_VECTOR]
FILE RAW = $(NAMED_GUID) {
RAW BIN Align = 16 |.bin
}
-
-[Rule.Common.SMM_CORE]
- FILE SMM_CORE = $(NAMED_GUID) {
- PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
- UI STRING="$(MODULE_NAME)" Optional
- VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
- }
-
-[Rule.Common.DXE_SMM_DRIVER]
- FILE SMM = $(NAMED_GUID) {
- SMM_DEPEX SMM_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
- PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
- UI STRING="$(MODULE_NAME)" Optional
- VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
- }
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-10 9:32 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-10 9:32 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This is a copy of OvmfX64, removing VirtIO and some SMM.
>
> This new platform will be changed to make it works on two types of Xen
> guest: HVM and PVH.
>
> Compare to OvmfX64, this patch:
>
> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
> - removed: VirtioLib class resolution
> - removed: all UEFI_DRIVER modules for virtio devices
> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
> - removed: Everything related to SMM_REQUIRE==true
> - removed: Everything related to SECURE_BOOT_ENABLE==true
> - removed: Everything related to TPM2_ENABLE==true
> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
> - changed: default FD_SIZE_IN_KB to 2M.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
> OvmfPkg/{OvmfPkgIa32X64.fdf => XenOvmf.fdf} | 72 +------
> 2 files changed, 12 insertions(+), 262 deletions(-)
Nicely done (and nicely formatted for review too), thanks.
I have some suggestions:
(1) in the commit message, it might be worth mentioning (additionally)
that we undo commit d272449d9e1e ("OvmfPkg: raise DXEFV size to 11 MB",
2018-05-29).
(2) Please don't forget to rename & replace XenOvmf -> OvmfXen (in file
names, the commit message, and the patch body).
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/XenOvmf.dsc
> similarity index 79%
> copy from OvmfPkg/OvmfPkgX64.dsc
> copy to OvmfPkg/XenOvmf.dsc
> index 2943e9e8af..bfe9190735 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -3,6 +3,7 @@
> #
> # Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
> # (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> @@ -21,26 +22,22 @@
> ################################################################################
> [Defines]
> PLATFORM_NAME = Ovmf
> - PLATFORM_GUID = 5a9e7754-d81b-49ea-85ad-69eaa7b1539b
> + PLATFORM_GUID = e3aa4fbe-9459-482d-bd40-d3f3b5f89d6e
> PLATFORM_VERSION = 0.1
> DSC_SPECIFICATION = 0x00010005
> - OUTPUT_DIRECTORY = Build/OvmfX64
> + OUTPUT_DIRECTORY = Build/XenOvmf
> SUPPORTED_ARCHITECTURES = X64
> BUILD_TARGETS = NOOPT|DEBUG|RELEASE
> SKUID_IDENTIFIER = DEFAULT
> - FLASH_DEFINITION = OvmfPkg/OvmfPkgX64.fdf
> + FLASH_DEFINITION = OvmfPkg/XenOvmf.fdf
>
> #
> # Defines for default states. These can be changed on the command line.
> # -D FLAG=VALUE
> #
> - DEFINE SECURE_BOOT_ENABLE = FALSE
> DEFINE NETWORK_IP6_ENABLE = FALSE
> DEFINE HTTP_BOOT_ENABLE = FALSE
> - DEFINE SMM_REQUIRE = FALSE
> DEFINE TLS_ENABLE = FALSE
> - DEFINE TPM2_ENABLE = FALSE
> - DEFINE TPM2_CONFIG_ENABLE = FALSE
> DEFINE USE_LEGACY_ISA_STACK = FALSE
>
> #
> @@ -57,7 +54,7 @@ [Defines]
> !ifdef $(FD_SIZE_4MB)
> DEFINE FD_SIZE_IN_KB = 4096
> !else
> - DEFINE FD_SIZE_IN_KB = 4096
> + DEFINE FD_SIZE_IN_KB = 2048
> !endif
> !endif
> !endif
> @@ -157,12 +154,9 @@ [LibraryClasses]
> UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
> SerializeVariablesLib|OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.inf
> QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxeLib.inf
> - VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
> LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
> MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
> -!if $(SMM_REQUIRE) == FALSE
> LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
> -!endif
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>
> @@ -185,14 +179,8 @@ [LibraryClasses]
> OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> !endif
>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
> - TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
> - AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
> -!else
> TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
> AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
> -!endif
> VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
>
> TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
> @@ -211,13 +199,7 @@ [LibraryClasses]
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>
> -!if $(TPM2_ENABLE) == TRUE
> - Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
> - Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
> - Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
> -!else
> Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
> -!endif
>
> [LibraryClasses.common]
> BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> @@ -283,11 +265,6 @@ [LibraryClasses.common.PEIM]
> PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf
>
> -!if $(TPM2_ENABLE) == TRUE
> - BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
> - Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
> -!endif
> -
> [LibraryClasses.common.DXE_CORE]
> HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
> DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
> @@ -357,20 +334,13 @@ [LibraryClasses.common.DXE_DRIVER]
> PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
> QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
> -!if $(SMM_REQUIRE) == TRUE
> - LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
> -!else
> LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
> -!endif
> !ifdef $(SOURCE_DEBUG_ENABLE)
> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
> !endif
> PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
> MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
> -!if $(TPM2_ENABLE) == TRUE
> - Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
> -!endif
>
> [LibraryClasses.common.UEFI_APPLICATION]
> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> @@ -385,43 +355,6 @@ [LibraryClasses.common.UEFI_APPLICATION]
> !endif
> PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>
> -[LibraryClasses.common.DXE_SMM_DRIVER]
> - PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> - MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
> - ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> - HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> - SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> - MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
> - SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> -!ifdef $(DEBUG_ON_SERIAL_PORT)
> - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> -!else
> - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> -!endif
> - CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
> -!ifdef $(SOURCE_DEBUG_ENABLE)
> - DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
> -!endif
> - BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
> - PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
> -
> -[LibraryClasses.common.SMM_CORE]
> - PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> - SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
> - MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
> - ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> - HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> - SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> - SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
> -!ifdef $(DEBUG_ON_SERIAL_PORT)
> - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> -!else
> - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> -!endif
> - PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
> -
> ################################################################################
> #
> # Pcd Section - list of all EDK II PCD Entries defined by this Platform.
> @@ -436,10 +369,6 @@ [PcdsFeatureFlag]
> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
> gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
> -!if $(SMM_REQUIRE) == TRUE
> - gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
> -!endif
>
> [PcdsFixedAtBuild]
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
> @@ -516,10 +445,6 @@ [PcdsFixedAtBuild]
>
> gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
>
> -!if $(SMM_REQUIRE) == TRUE
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
> -!endif
> -
> # IRQs 5, 9, 10, 11 are level-triggered
> gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>
> @@ -533,14 +458,11 @@ [PcdsFixedAtBuild]
> ################################################################################
>
> [PcdsDynamicDefault]
> - # only set when
> - # ($(SMM_REQUIRE) == FALSE)
> gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
> -
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
> - gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE
> + gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|TRUE
> gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800
> gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
> gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable|FALSE
> @@ -573,18 +495,8 @@ [PcdsDynamicDefault]
> # Set memory encryption mask
> gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
>
> -!if $(SMM_REQUIRE) == TRUE
> - gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000
> -!endif
> -
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
>
> -!if $(TPM2_ENABLE) == TRUE
> - gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
> -!endif
> -
> ################################################################################
> #
> # Components Section - list of all EDK II Modules needed by this Platform.
> @@ -620,32 +532,9 @@ [Components]
> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>
> OvmfPkg/PlatformPei/PlatformPei.inf
> - UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
> - <LibraryClasses>
> -!if $(SMM_REQUIRE) == TRUE
> - LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
> -!endif
> - }
> -!if $(SMM_REQUIRE) == TRUE
> - OvmfPkg/SmmAccess/SmmAccessPei.inf
> -!endif
> + UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> UefiCpuPkg/CpuMpPei/CpuMpPei.inf
>
> -!if $(TPM2_ENABLE) == TRUE
> - OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
> - SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf {
> - <LibraryClasses>
> - HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
> - }
> -!if $(TPM2_CONFIG_ENABLE) == TRUE
> - SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
> -!endif
> -!endif
> -
> #
> # DXE Phase modules
> #
> @@ -664,15 +553,7 @@ [Components]
>
> MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>
> - MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
> - <LibraryClasses>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
> -!endif
> -!if $(TPM2_ENABLE) == TRUE
> - NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf
> -!endif
> - }
> + MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>
> MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> @@ -712,11 +593,6 @@ [Components]
> NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> !endif
> }
> - OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> - OvmfPkg/Virtio10Dxe/Virtio10.inf
> - OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> - OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
> - OvmfPkg/VirtioRngDxe/VirtioRng.inf
> OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> OvmfPkg/XenBusDxe/XenBusDxe.inf
> OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> @@ -755,7 +631,6 @@ [Components]
>
> OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
> - OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>
> #
> # ISA Support
> @@ -824,7 +699,6 @@ [Components]
> NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
> }
> !endif
> - OvmfPkg/VirtioNetDxe/VirtioNet.inf
>
> #
> # Usb Support
> @@ -874,56 +748,10 @@ [Components]
> gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
> }
>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> -!endif
> -
> OvmfPkg/PlatformDxe/Platform.inf
> OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> OvmfPkg/IoMmuDxe/IoMmuDxe.inf
>
> -!if $(SMM_REQUIRE) == TRUE
> - OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
> - OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> - UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> -
> - #
> - # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
> - #
> - MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
> -
> - #
> - # SMM_CORE
> - #
> - MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> -
> - #
> - # Privileged drivers (DXE_SMM_DRIVER modules)
> - #
> - UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
> - MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf {
> - <LibraryClasses>
> - LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
> - }
> - UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
> - <LibraryClasses>
> - SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
> - SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> - }
> -
> - #
> - # Variable driver stack (SMM)
> - #
> - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
> - MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
> - MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
> - <LibraryClasses>
> - NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> - }
> - MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
> -
> -!else
> -
> #
> # Variable driver stack (non-SMM)
> #
> @@ -937,17 +765,3 @@ [Components]
> <LibraryClasses>
> NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> }
> -!endif
> -
> -!if $(TPM2_ENABLE) == TRUE
> - SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf {
> - <LibraryClasses>
> - Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
> - NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf
> - HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
> - }
> -!endif
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/XenOvmf.fdf
> similarity index 85%
> copy from OvmfPkg/OvmfPkgIa32X64.fdf
> copy to OvmfPkg/XenOvmf.fdf
> index 6c40540202..612ffb2e01 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -3,6 +3,7 @@
> #
> # Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
> # (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> @@ -68,10 +69,10 @@ [FD.OVMF_CODE]
>
> [FD.MEMFD]
> BaseAddress = $(MEMFD_BASE_ADDRESS)
> -Size = 0xC00000
> +Size = 0xB00000
> ErasePolarity = 1
> BlockSize = 0x10000
> -NumBlocks = 0xC0
> +NumBlocks = 0xB0
>
> 0x000000|0x006000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> @@ -89,7 +90,7 @@ [FD.MEMFD]
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
> FV = PEIFV
>
> -0x100000|0xB00000
> +0x100000|0xA00000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> FV = DXEFV
>
> @@ -160,16 +161,8 @@ [FV.PEIFV]
> INF OvmfPkg/PlatformPei/PlatformPei.inf
> INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> -!if $(SMM_REQUIRE) == TRUE
> -INF OvmfPkg/SmmAccess/SmmAccessPei.inf
> -!endif
> INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
>
> -!if $(TPM2_ENABLE) == TRUE
> -INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
> -INF SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
> -!endif
> -
> ################################################################################
>
> [FV.DXEFV]
> @@ -197,9 +190,6 @@ [FV.DXEFV]
> INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
> INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> -!if $(SMM_REQUIRE) == FALSE
> - INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> -!endif
> }
(3) Here you diverge from the general pattern of:
- SMM_REQUIRE==TRUE --> drop the full block
- SMM_REQUIRE==FALSE --> drop the condition, keep the block
For consistency with the pattern, you sould *in theory* only drop the
condition.
Let's see what this change effects.
You remove the driver from the APRIORI DXE file. That means the DXE Core
will be at liberty to launch the driver at any time, provided DEPEXes
are satisfied.
This wouldn't be correct for the original FDF file, because there we
need an arbitration between this driver and the emulation driver,
dependent on flash detection. Therefore the original platform first
launches the flash driver, and falls back to the emu driver if flash is
not present. Except in case of SMM_REQUIRE, in which case *both* of
those drivers are replaced by the SMM flash driver (and no arbitration
occurs, because flash is a hard requirement).
On Xen, SMM_REQUIRE is indeed assumed FALSE, but we also don't really
need the arbitration, because we know the flash detection will always
fail. Therefore, it is correct to remove the flash driver from the
APRIORI DXE file -- but then, shouldn't we remove the driver itself from
the DSC and FDF files too?
I mean, if it doesn't matter *when* it is launched, then you don't need
to launch it *at all*, I believe.
If you agree, then it's OK (but not required) to split this change to a
separate patch -- as I said it diverges from the general pattern and may
deserve a bit more explanation.
(4) You might want to remove/revert SEV-related modules as well (I'm
unsure if AMD SEV works on Xen -- if it does, then please ignore):
- IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
(refer to "git blame" to see what to revert it to)
-
MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
- NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
- OvmfPkg/AmdSevDxe/AmdSevDxe.inf
- OvmfPkg/IoMmuDxe/IoMmuDxe.inf
This can be a separate patch again.
(5) I think you could change the QemuFwCfgS3Lib resolution to
"BaseQemuFwCfgS3LibNull.inf", and then remove all the S3 modules --
search OvmfPkg, and generally the edk2 tree, for " PcdAcpiS3Enable".
See also module names having "S3" in the name, in the FDF/DSC files.
This would probably be a separate patch.
Thanks,
Laszlo
>
> #
> @@ -226,19 +216,10 @@ [FV.DXEFV]
> INF MdeModulePkg/Universal/Metronome/Metronome.inf
> INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
>
> -INF OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> -INF OvmfPkg/Virtio10Dxe/Virtio10.inf
> -INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> -INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
> -INF OvmfPkg/VirtioRngDxe/VirtioRng.inf
> INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> INF OvmfPkg/XenBusDxe/XenBusDxe.inf
> INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - INF SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> -!endif
> -
> INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
> INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
> INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> @@ -337,7 +318,6 @@ [FV.DXEFV]
> INF NetworkPkg/TlsDxe/TlsDxe.inf
> INF NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
> !endif
> - INF OvmfPkg/VirtioNetDxe/VirtioNet.inf
>
> #
> # Usb Support
> @@ -357,31 +337,10 @@ [FV.DXEFV]
>
> INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
> -INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> INF OvmfPkg/PlatformDxe/Platform.inf
> INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> INF OvmfPkg/IoMmuDxe/IoMmuDxe.inf
>
> -!if $(SMM_REQUIRE) == TRUE
> -INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
> -INF OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> -INF UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> -INF MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
> -INF MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> -INF UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
> -INF MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
> -INF UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
> -
> -#
> -# Variable driver stack (SMM)
> -#
> -INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
> -INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
> -INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> -INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
> -
> -!else
> -
> #
> # Variable driver stack (non-SMM)
> #
> @@ -389,14 +348,6 @@ [FV.DXEFV]
> INF OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
> INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
> INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
> -!endif
> -
> -!if $(TPM2_ENABLE) == TRUE
> -INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
> -!if $(TPM2_CONFIG_ENABLE) == TRUE
> -INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
> -!endif
> -!endif
>
> ################################################################################
>
> @@ -527,18 +478,3 @@ [Rule.Common.SEC.RESET_VECTOR]
> FILE RAW = $(NAMED_GUID) {
> RAW BIN Align = 16 |.bin
> }
> -
> -[Rule.Common.SMM_CORE]
> - FILE SMM_CORE = $(NAMED_GUID) {
> - PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
> - UI STRING="$(MODULE_NAME)" Optional
> - VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
> - }
> -
> -[Rule.Common.DXE_SMM_DRIVER]
> - FILE SMM = $(NAMED_GUID) {
> - SMM_DEPEX SMM_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
> - PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
> - UI STRING="$(MODULE_NAME)" Optional
> - VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
> - }
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-10 9:32 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-10 9:32 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This is a copy of OvmfX64, removing VirtIO and some SMM.
>
> This new platform will be changed to make it works on two types of Xen
> guest: HVM and PVH.
>
> Compare to OvmfX64, this patch:
>
> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
> - removed: VirtioLib class resolution
> - removed: all UEFI_DRIVER modules for virtio devices
> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
> - removed: Everything related to SMM_REQUIRE==true
> - removed: Everything related to SECURE_BOOT_ENABLE==true
> - removed: Everything related to TPM2_ENABLE==true
> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
> - changed: default FD_SIZE_IN_KB to 2M.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
> OvmfPkg/{OvmfPkgIa32X64.fdf => XenOvmf.fdf} | 72 +------
> 2 files changed, 12 insertions(+), 262 deletions(-)
Nicely done (and nicely formatted for review too), thanks.
I have some suggestions:
(1) in the commit message, it might be worth mentioning (additionally)
that we undo commit d272449d9e1e ("OvmfPkg: raise DXEFV size to 11 MB",
2018-05-29).
(2) Please don't forget to rename & replace XenOvmf -> OvmfXen (in file
names, the commit message, and the patch body).
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/XenOvmf.dsc
> similarity index 79%
> copy from OvmfPkg/OvmfPkgX64.dsc
> copy to OvmfPkg/XenOvmf.dsc
> index 2943e9e8af..bfe9190735 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -3,6 +3,7 @@
> #
> # Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
> # (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> @@ -21,26 +22,22 @@
> ################################################################################
> [Defines]
> PLATFORM_NAME = Ovmf
> - PLATFORM_GUID = 5a9e7754-d81b-49ea-85ad-69eaa7b1539b
> + PLATFORM_GUID = e3aa4fbe-9459-482d-bd40-d3f3b5f89d6e
> PLATFORM_VERSION = 0.1
> DSC_SPECIFICATION = 0x00010005
> - OUTPUT_DIRECTORY = Build/OvmfX64
> + OUTPUT_DIRECTORY = Build/XenOvmf
> SUPPORTED_ARCHITECTURES = X64
> BUILD_TARGETS = NOOPT|DEBUG|RELEASE
> SKUID_IDENTIFIER = DEFAULT
> - FLASH_DEFINITION = OvmfPkg/OvmfPkgX64.fdf
> + FLASH_DEFINITION = OvmfPkg/XenOvmf.fdf
>
> #
> # Defines for default states. These can be changed on the command line.
> # -D FLAG=VALUE
> #
> - DEFINE SECURE_BOOT_ENABLE = FALSE
> DEFINE NETWORK_IP6_ENABLE = FALSE
> DEFINE HTTP_BOOT_ENABLE = FALSE
> - DEFINE SMM_REQUIRE = FALSE
> DEFINE TLS_ENABLE = FALSE
> - DEFINE TPM2_ENABLE = FALSE
> - DEFINE TPM2_CONFIG_ENABLE = FALSE
> DEFINE USE_LEGACY_ISA_STACK = FALSE
>
> #
> @@ -57,7 +54,7 @@ [Defines]
> !ifdef $(FD_SIZE_4MB)
> DEFINE FD_SIZE_IN_KB = 4096
> !else
> - DEFINE FD_SIZE_IN_KB = 4096
> + DEFINE FD_SIZE_IN_KB = 2048
> !endif
> !endif
> !endif
> @@ -157,12 +154,9 @@ [LibraryClasses]
> UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
> SerializeVariablesLib|OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.inf
> QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxeLib.inf
> - VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
> LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
> MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
> -!if $(SMM_REQUIRE) == FALSE
> LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
> -!endif
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>
> @@ -185,14 +179,8 @@ [LibraryClasses]
> OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> !endif
>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
> - TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
> - AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
> -!else
> TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
> AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
> -!endif
> VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
>
> TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
> @@ -211,13 +199,7 @@ [LibraryClasses]
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>
> -!if $(TPM2_ENABLE) == TRUE
> - Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
> - Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
> - Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
> -!else
> Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
> -!endif
>
> [LibraryClasses.common]
> BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> @@ -283,11 +265,6 @@ [LibraryClasses.common.PEIM]
> PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf
>
> -!if $(TPM2_ENABLE) == TRUE
> - BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
> - Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
> -!endif
> -
> [LibraryClasses.common.DXE_CORE]
> HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
> DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
> @@ -357,20 +334,13 @@ [LibraryClasses.common.DXE_DRIVER]
> PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
> QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
> -!if $(SMM_REQUIRE) == TRUE
> - LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
> -!else
> LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
> -!endif
> !ifdef $(SOURCE_DEBUG_ENABLE)
> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
> !endif
> PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
> MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
> -!if $(TPM2_ENABLE) == TRUE
> - Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
> -!endif
>
> [LibraryClasses.common.UEFI_APPLICATION]
> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> @@ -385,43 +355,6 @@ [LibraryClasses.common.UEFI_APPLICATION]
> !endif
> PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>
> -[LibraryClasses.common.DXE_SMM_DRIVER]
> - PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> - MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
> - ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> - HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> - SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> - MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
> - SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> -!ifdef $(DEBUG_ON_SERIAL_PORT)
> - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> -!else
> - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> -!endif
> - CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
> -!ifdef $(SOURCE_DEBUG_ENABLE)
> - DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
> -!endif
> - BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
> - PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
> -
> -[LibraryClasses.common.SMM_CORE]
> - PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> - SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
> - MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
> - ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> - HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> - SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> - SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
> -!ifdef $(DEBUG_ON_SERIAL_PORT)
> - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> -!else
> - DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> -!endif
> - PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
> -
> ################################################################################
> #
> # Pcd Section - list of all EDK II PCD Entries defined by this Platform.
> @@ -436,10 +369,6 @@ [PcdsFeatureFlag]
> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
> gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
> -!if $(SMM_REQUIRE) == TRUE
> - gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
> -!endif
>
> [PcdsFixedAtBuild]
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
> @@ -516,10 +445,6 @@ [PcdsFixedAtBuild]
>
> gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
>
> -!if $(SMM_REQUIRE) == TRUE
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
> -!endif
> -
> # IRQs 5, 9, 10, 11 are level-triggered
> gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>
> @@ -533,14 +458,11 @@ [PcdsFixedAtBuild]
> ################################################################################
>
> [PcdsDynamicDefault]
> - # only set when
> - # ($(SMM_REQUIRE) == FALSE)
> gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
> -
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
> - gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE
> + gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|TRUE
> gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800
> gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
> gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable|FALSE
> @@ -573,18 +495,8 @@ [PcdsDynamicDefault]
> # Set memory encryption mask
> gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
>
> -!if $(SMM_REQUIRE) == TRUE
> - gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000
> -!endif
> -
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
>
> -!if $(TPM2_ENABLE) == TRUE
> - gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
> -!endif
> -
> ################################################################################
> #
> # Components Section - list of all EDK II Modules needed by this Platform.
> @@ -620,32 +532,9 @@ [Components]
> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>
> OvmfPkg/PlatformPei/PlatformPei.inf
> - UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
> - <LibraryClasses>
> -!if $(SMM_REQUIRE) == TRUE
> - LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
> -!endif
> - }
> -!if $(SMM_REQUIRE) == TRUE
> - OvmfPkg/SmmAccess/SmmAccessPei.inf
> -!endif
> + UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> UefiCpuPkg/CpuMpPei/CpuMpPei.inf
>
> -!if $(TPM2_ENABLE) == TRUE
> - OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
> - SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf {
> - <LibraryClasses>
> - HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
> - }
> -!if $(TPM2_CONFIG_ENABLE) == TRUE
> - SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
> -!endif
> -!endif
> -
> #
> # DXE Phase modules
> #
> @@ -664,15 +553,7 @@ [Components]
>
> MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>
> - MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
> - <LibraryClasses>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
> -!endif
> -!if $(TPM2_ENABLE) == TRUE
> - NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf
> -!endif
> - }
> + MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>
> MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> @@ -712,11 +593,6 @@ [Components]
> NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> !endif
> }
> - OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> - OvmfPkg/Virtio10Dxe/Virtio10.inf
> - OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> - OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
> - OvmfPkg/VirtioRngDxe/VirtioRng.inf
> OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> OvmfPkg/XenBusDxe/XenBusDxe.inf
> OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> @@ -755,7 +631,6 @@ [Components]
>
> OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
> - OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>
> #
> # ISA Support
> @@ -824,7 +699,6 @@ [Components]
> NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
> }
> !endif
> - OvmfPkg/VirtioNetDxe/VirtioNet.inf
>
> #
> # Usb Support
> @@ -874,56 +748,10 @@ [Components]
> gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
> }
>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> -!endif
> -
> OvmfPkg/PlatformDxe/Platform.inf
> OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> OvmfPkg/IoMmuDxe/IoMmuDxe.inf
>
> -!if $(SMM_REQUIRE) == TRUE
> - OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
> - OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> - UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> -
> - #
> - # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
> - #
> - MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
> -
> - #
> - # SMM_CORE
> - #
> - MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> -
> - #
> - # Privileged drivers (DXE_SMM_DRIVER modules)
> - #
> - UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
> - MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf {
> - <LibraryClasses>
> - LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
> - }
> - UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
> - <LibraryClasses>
> - SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
> - SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> - }
> -
> - #
> - # Variable driver stack (SMM)
> - #
> - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
> - MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
> - MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
> - <LibraryClasses>
> - NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> - }
> - MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
> -
> -!else
> -
> #
> # Variable driver stack (non-SMM)
> #
> @@ -937,17 +765,3 @@ [Components]
> <LibraryClasses>
> NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> }
> -!endif
> -
> -!if $(TPM2_ENABLE) == TRUE
> - SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf {
> - <LibraryClasses>
> - Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
> - NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf
> - HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
> - NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
> - }
> -!endif
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/XenOvmf.fdf
> similarity index 85%
> copy from OvmfPkg/OvmfPkgIa32X64.fdf
> copy to OvmfPkg/XenOvmf.fdf
> index 6c40540202..612ffb2e01 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -3,6 +3,7 @@
> #
> # Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
> # (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> @@ -68,10 +69,10 @@ [FD.OVMF_CODE]
>
> [FD.MEMFD]
> BaseAddress = $(MEMFD_BASE_ADDRESS)
> -Size = 0xC00000
> +Size = 0xB00000
> ErasePolarity = 1
> BlockSize = 0x10000
> -NumBlocks = 0xC0
> +NumBlocks = 0xB0
>
> 0x000000|0x006000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> @@ -89,7 +90,7 @@ [FD.MEMFD]
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
> FV = PEIFV
>
> -0x100000|0xB00000
> +0x100000|0xA00000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> FV = DXEFV
>
> @@ -160,16 +161,8 @@ [FV.PEIFV]
> INF OvmfPkg/PlatformPei/PlatformPei.inf
> INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> -!if $(SMM_REQUIRE) == TRUE
> -INF OvmfPkg/SmmAccess/SmmAccessPei.inf
> -!endif
> INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
>
> -!if $(TPM2_ENABLE) == TRUE
> -INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
> -INF SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
> -!endif
> -
> ################################################################################
>
> [FV.DXEFV]
> @@ -197,9 +190,6 @@ [FV.DXEFV]
> INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
> INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> -!if $(SMM_REQUIRE) == FALSE
> - INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> -!endif
> }
(3) Here you diverge from the general pattern of:
- SMM_REQUIRE==TRUE --> drop the full block
- SMM_REQUIRE==FALSE --> drop the condition, keep the block
For consistency with the pattern, you sould *in theory* only drop the
condition.
Let's see what this change effects.
You remove the driver from the APRIORI DXE file. That means the DXE Core
will be at liberty to launch the driver at any time, provided DEPEXes
are satisfied.
This wouldn't be correct for the original FDF file, because there we
need an arbitration between this driver and the emulation driver,
dependent on flash detection. Therefore the original platform first
launches the flash driver, and falls back to the emu driver if flash is
not present. Except in case of SMM_REQUIRE, in which case *both* of
those drivers are replaced by the SMM flash driver (and no arbitration
occurs, because flash is a hard requirement).
On Xen, SMM_REQUIRE is indeed assumed FALSE, but we also don't really
need the arbitration, because we know the flash detection will always
fail. Therefore, it is correct to remove the flash driver from the
APRIORI DXE file -- but then, shouldn't we remove the driver itself from
the DSC and FDF files too?
I mean, if it doesn't matter *when* it is launched, then you don't need
to launch it *at all*, I believe.
If you agree, then it's OK (but not required) to split this change to a
separate patch -- as I said it diverges from the general pattern and may
deserve a bit more explanation.
(4) You might want to remove/revert SEV-related modules as well (I'm
unsure if AMD SEV works on Xen -- if it does, then please ignore):
- IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
(refer to "git blame" to see what to revert it to)
-
MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
- NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
- OvmfPkg/AmdSevDxe/AmdSevDxe.inf
- OvmfPkg/IoMmuDxe/IoMmuDxe.inf
This can be a separate patch again.
(5) I think you could change the QemuFwCfgS3Lib resolution to
"BaseQemuFwCfgS3LibNull.inf", and then remove all the S3 modules --
search OvmfPkg, and generally the edk2 tree, for " PcdAcpiS3Enable".
See also module names having "S3" in the name, in the FDF/DSC files.
This would probably be a separate patch.
Thanks,
Laszlo
>
> #
> @@ -226,19 +216,10 @@ [FV.DXEFV]
> INF MdeModulePkg/Universal/Metronome/Metronome.inf
> INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
>
> -INF OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> -INF OvmfPkg/Virtio10Dxe/Virtio10.inf
> -INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> -INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
> -INF OvmfPkg/VirtioRngDxe/VirtioRng.inf
> INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> INF OvmfPkg/XenBusDxe/XenBusDxe.inf
> INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - INF SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> -!endif
> -
> INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
> INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
> INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> @@ -337,7 +318,6 @@ [FV.DXEFV]
> INF NetworkPkg/TlsDxe/TlsDxe.inf
> INF NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
> !endif
> - INF OvmfPkg/VirtioNetDxe/VirtioNet.inf
>
> #
> # Usb Support
> @@ -357,31 +337,10 @@ [FV.DXEFV]
>
> INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
> -INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> INF OvmfPkg/PlatformDxe/Platform.inf
> INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> INF OvmfPkg/IoMmuDxe/IoMmuDxe.inf
>
> -!if $(SMM_REQUIRE) == TRUE
> -INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
> -INF OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> -INF UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> -INF MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
> -INF MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> -INF UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
> -INF MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
> -INF UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
> -
> -#
> -# Variable driver stack (SMM)
> -#
> -INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
> -INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
> -INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> -INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
> -
> -!else
> -
> #
> # Variable driver stack (non-SMM)
> #
> @@ -389,14 +348,6 @@ [FV.DXEFV]
> INF OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
> INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
> INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
> -!endif
> -
> -!if $(TPM2_ENABLE) == TRUE
> -INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
> -!if $(TPM2_CONFIG_ENABLE) == TRUE
> -INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
> -!endif
> -!endif
>
> ################################################################################
>
> @@ -527,18 +478,3 @@ [Rule.Common.SEC.RESET_VECTOR]
> FILE RAW = $(NAMED_GUID) {
> RAW BIN Align = 16 |.bin
> }
> -
> -[Rule.Common.SMM_CORE]
> - FILE SMM_CORE = $(NAMED_GUID) {
> - PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
> - UI STRING="$(MODULE_NAME)" Optional
> - VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
> - }
> -
> -[Rule.Common.DXE_SMM_DRIVER]
> - FILE SMM = $(NAMED_GUID) {
> - SMM_DEPEX SMM_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
> - PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
> - UI STRING="$(MODULE_NAME)" Optional
> - VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
> - }
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-15 10:53 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-15 10:53 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Jordan Justen, devel, xen-devel, Julien Grall, Ard Biesheuvel
On Wed, Apr 10, 2019 at 11:32:10AM +0200, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
> > This is a copy of OvmfX64, removing VirtIO and some SMM.
> >
> > This new platform will be changed to make it works on two types of Xen
> > guest: HVM and PVH.
> >
> > Compare to OvmfX64, this patch:
> >
> > - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
> > - removed: VirtioLib class resolution
> > - removed: all UEFI_DRIVER modules for virtio devices
> > - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
> > - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
> > - removed: Everything related to SMM_REQUIRE==true
> > - removed: Everything related to SECURE_BOOT_ENABLE==true
> > - removed: Everything related to TPM2_ENABLE==true
> > - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
> > - changed: default FD_SIZE_IN_KB to 2M.
> >
>
> (1) in the commit message, it might be worth mentioning (additionally)
> that we undo commit d272449d9e1e ("OvmfPkg: raise DXEFV size to 11 MB",
> 2018-05-29).
Will do.
> (2) Please don't forget to rename & replace XenOvmf -> OvmfXen (in file
> names, the commit message, and the patch body).
Will do.
> > diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/XenOvmf.fdf
> > similarity index 85%
> > copy from OvmfPkg/OvmfPkgIa32X64.fdf
> > copy to OvmfPkg/XenOvmf.fdf
> > index 6c40540202..612ffb2e01 100644
> > --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> > +++ b/OvmfPkg/XenOvmf.fdf
> > @@ -197,9 +190,6 @@ [FV.DXEFV]
> > INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> > INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
> > INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> > -!if $(SMM_REQUIRE) == FALSE
> > - INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> > -!endif
> > }
>
> (3) Here you diverge from the general pattern of:
> - SMM_REQUIRE==TRUE --> drop the full block
> - SMM_REQUIRE==FALSE --> drop the condition, keep the block
>
> For consistency with the pattern, you sould *in theory* only drop the
> condition.
>
> Let's see what this change effects.
>
> You remove the driver from the APRIORI DXE file. That means the DXE Core
> will be at liberty to launch the driver at any time, provided DEPEXes
> are satisfied.
>
> This wouldn't be correct for the original FDF file, because there we
> need an arbitration between this driver and the emulation driver,
> dependent on flash detection. Therefore the original platform first
> launches the flash driver, and falls back to the emu driver if flash is
> not present. Except in case of SMM_REQUIRE, in which case *both* of
> those drivers are replaced by the SMM flash driver (and no arbitration
> occurs, because flash is a hard requirement).
>
> On Xen, SMM_REQUIRE is indeed assumed FALSE, but we also don't really
> need the arbitration, because we know the flash detection will always
> fail. Therefore, it is correct to remove the flash driver from the
> APRIORI DXE file -- but then, shouldn't we remove the driver itself from
> the DSC and FDF files too?
>
> I mean, if it doesn't matter *when* it is launched, then you don't need
> to launch it *at all*, I believe.
>
> If you agree, then it's OK (but not required) to split this change to a
> separate patch -- as I said it diverges from the general pattern and may
> deserve a bit more explanation.
I think that was removed by mistake, otherwise I think I would have
removed QemuFlashFvbServicesRuntimeDxe completely. I do some tests, and
if I do need to remove it from the APRIORI list, I do that in a
separated patch.
> (4) You might want to remove/revert SEV-related modules as well (I'm
> unsure if AMD SEV works on Xen -- if it does, then please ignore):
>
> - IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
>
> (refer to "git blame" to see what to revert it to)
>
> -
> MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
>
> - NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
>
> - OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> - OvmfPkg/IoMmuDxe/IoMmuDxe.inf
>
> This can be a separate patch again.
Thanks for the suggestion. It probably doesn't hurt to keep the
SEV-related modules, so I think I'll keep them for now.
> (5) I think you could change the QemuFwCfgS3Lib resolution to
> "BaseQemuFwCfgS3LibNull.inf", and then remove all the S3 modules --
> search OvmfPkg, and generally the edk2 tree, for " PcdAcpiS3Enable".
>
> See also module names having "S3" in the name, in the FDF/DSC files.
>
> This would probably be a separate patch.
I'll have a look, thanks.
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-15 10:53 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-15 10:53 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Jordan Justen, devel, xen-devel, Julien Grall, Ard Biesheuvel
On Wed, Apr 10, 2019 at 11:32:10AM +0200, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
> > This is a copy of OvmfX64, removing VirtIO and some SMM.
> >
> > This new platform will be changed to make it works on two types of Xen
> > guest: HVM and PVH.
> >
> > Compare to OvmfX64, this patch:
> >
> > - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
> > - removed: VirtioLib class resolution
> > - removed: all UEFI_DRIVER modules for virtio devices
> > - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
> > - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
> > - removed: Everything related to SMM_REQUIRE==true
> > - removed: Everything related to SECURE_BOOT_ENABLE==true
> > - removed: Everything related to TPM2_ENABLE==true
> > - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
> > - changed: default FD_SIZE_IN_KB to 2M.
> >
>
> (1) in the commit message, it might be worth mentioning (additionally)
> that we undo commit d272449d9e1e ("OvmfPkg: raise DXEFV size to 11 MB",
> 2018-05-29).
Will do.
> (2) Please don't forget to rename & replace XenOvmf -> OvmfXen (in file
> names, the commit message, and the patch body).
Will do.
> > diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/XenOvmf.fdf
> > similarity index 85%
> > copy from OvmfPkg/OvmfPkgIa32X64.fdf
> > copy to OvmfPkg/XenOvmf.fdf
> > index 6c40540202..612ffb2e01 100644
> > --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> > +++ b/OvmfPkg/XenOvmf.fdf
> > @@ -197,9 +190,6 @@ [FV.DXEFV]
> > INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> > INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
> > INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> > -!if $(SMM_REQUIRE) == FALSE
> > - INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> > -!endif
> > }
>
> (3) Here you diverge from the general pattern of:
> - SMM_REQUIRE==TRUE --> drop the full block
> - SMM_REQUIRE==FALSE --> drop the condition, keep the block
>
> For consistency with the pattern, you sould *in theory* only drop the
> condition.
>
> Let's see what this change effects.
>
> You remove the driver from the APRIORI DXE file. That means the DXE Core
> will be at liberty to launch the driver at any time, provided DEPEXes
> are satisfied.
>
> This wouldn't be correct for the original FDF file, because there we
> need an arbitration between this driver and the emulation driver,
> dependent on flash detection. Therefore the original platform first
> launches the flash driver, and falls back to the emu driver if flash is
> not present. Except in case of SMM_REQUIRE, in which case *both* of
> those drivers are replaced by the SMM flash driver (and no arbitration
> occurs, because flash is a hard requirement).
>
> On Xen, SMM_REQUIRE is indeed assumed FALSE, but we also don't really
> need the arbitration, because we know the flash detection will always
> fail. Therefore, it is correct to remove the flash driver from the
> APRIORI DXE file -- but then, shouldn't we remove the driver itself from
> the DSC and FDF files too?
>
> I mean, if it doesn't matter *when* it is launched, then you don't need
> to launch it *at all*, I believe.
>
> If you agree, then it's OK (but not required) to split this change to a
> separate patch -- as I said it diverges from the general pattern and may
> deserve a bit more explanation.
I think that was removed by mistake, otherwise I think I would have
removed QemuFlashFvbServicesRuntimeDxe completely. I do some tests, and
if I do need to remove it from the APRIORI list, I do that in a
separated patch.
> (4) You might want to remove/revert SEV-related modules as well (I'm
> unsure if AMD SEV works on Xen -- if it does, then please ignore):
>
> - IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
>
> (refer to "git blame" to see what to revert it to)
>
> -
> MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
>
> - NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
>
> - OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> - OvmfPkg/IoMmuDxe/IoMmuDxe.inf
>
> This can be a separate patch again.
Thanks for the suggestion. It probably doesn't hurt to keep the
SEV-related modules, so I think I'll keep them for now.
> (5) I think you could change the QemuFwCfgS3Lib resolution to
> "BaseQemuFwCfgS3LibNull.inf", and then remove all the S3 modules --
> search OvmfPkg, and generally the edk2 tree, for " PcdAcpiS3Enable".
>
> See also module names having "S3" in the name, in the FDF/DSC files.
>
> This would probably be a separate patch.
I'll have a look, thanks.
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-10 9:48 ` Jordan Justen
0 siblings, 0 replies; 168+ messages in thread
From: Jordan Justen @ 2019-04-10 9:48 UTC (permalink / raw)
To: devel
Cc: Anthony PERARD, xen-devel, Julien Grall, Laszlo Ersek, Ard Biesheuvel
On 2019-04-09 04:08:15, Anthony PERARD wrote:
> This is a copy of OvmfX64, removing VirtIO and some SMM.
>
> This new platform will be changed to make it works on two types of Xen
> guest: HVM and PVH.
>
> Compare to OvmfX64, this patch:
>
> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
> - removed: VirtioLib class resolution
> - removed: all UEFI_DRIVER modules for virtio devices
> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
> - removed: Everything related to SMM_REQUIRE==true
> - removed: Everything related to SECURE_BOOT_ENABLE==true
> - removed: Everything related to TPM2_ENABLE==true
> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
> - changed: default FD_SIZE_IN_KB to 2M.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
I guess we all want our name to be first :), but OvmfXen seems more
like the pattern that edk2 uses when making sub-platforms.
Also, in some cases we've used !ifdef type things to keep dsc and fdf
files common. Would that not be workable here? Maybe it would get too
ugly. :\
It could help to prevent having to sync dsc changes across, and
prevent changes from being omitted for Xen on accident.
-Jordan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-10 9:48 ` Jordan Justen
0 siblings, 0 replies; 168+ messages in thread
From: Jordan Justen @ 2019-04-10 9:48 UTC (permalink / raw)
To: Anthony PERARD, devel
Cc: Anthony PERARD, xen-devel, Julien Grall, Laszlo Ersek, Ard Biesheuvel
On 2019-04-09 04:08:15, Anthony PERARD wrote:
> This is a copy of OvmfX64, removing VirtIO and some SMM.
>
> This new platform will be changed to make it works on two types of Xen
> guest: HVM and PVH.
>
> Compare to OvmfX64, this patch:
>
> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
> - removed: VirtioLib class resolution
> - removed: all UEFI_DRIVER modules for virtio devices
> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
> - removed: Everything related to SMM_REQUIRE==true
> - removed: Everything related to SECURE_BOOT_ENABLE==true
> - removed: Everything related to TPM2_ENABLE==true
> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
> - changed: default FD_SIZE_IN_KB to 2M.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
I guess we all want our name to be first :), but OvmfXen seems more
like the pattern that edk2 uses when making sub-platforms.
Also, in some cases we've used !ifdef type things to keep dsc and fdf
files common. Would that not be workable here? Maybe it would get too
ugly. :\
It could help to prevent having to sync dsc changes across, and
prevent changes from being omitted for Xen on accident.
-Jordan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-10 14:27 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-10 14:27 UTC (permalink / raw)
To: Jordan Justen, Anthony PERARD, devel
Cc: xen-devel, Julien Grall, Ard Biesheuvel
On 04/10/19 11:48, Jordan Justen wrote:
> On 2019-04-09 04:08:15, Anthony PERARD wrote:
>> This is a copy of OvmfX64, removing VirtIO and some SMM.
>>
>> This new platform will be changed to make it works on two types of Xen
>> guest: HVM and PVH.
>>
>> Compare to OvmfX64, this patch:
>>
>> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
>> - removed: VirtioLib class resolution
>> - removed: all UEFI_DRIVER modules for virtio devices
>> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
>> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
>> - removed: Everything related to SMM_REQUIRE==true
>> - removed: Everything related to SECURE_BOOT_ENABLE==true
>> - removed: Everything related to TPM2_ENABLE==true
>> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
>> - changed: default FD_SIZE_IN_KB to 2M.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
>
> I guess we all want our name to be first :), but OvmfXen seems more
> like the pattern that edk2 uses when making sub-platforms.
>
> Also, in some cases we've used !ifdef type things to keep dsc and fdf
> files common. Would that not be workable here? Maybe it would get too
> ugly. :\
I've been happy with a similar Xen<->QEMU split under ArmVirtPkg.
Duplications in updates are usually not a huge burden, and keeping the
files separate has proved very helpful for determining
maintainer/reviewer/tester responsibility.
> It could help to prevent having to sync dsc changes across, and
> prevent changes from being omitted for Xen on accident.
True, but in my experience that's been the smaller problem. The larger
problem has been modifying Xen stuff in unintended ways (= regressing
Xen), because we can't test (or don't even notice) the Xen-side
implications of changes made to common source.
Personally I prefer another (DSC + FDF) pair under OvmfPkg (beyond the
three we already have) to another layer of (conditional?) includes. The
!if's that are being eliminated in this Xen-customized copy (i.e., in
this patch) are complex enough already :)
... It's not that I *generally* prefer duplication; as you say, we do
have a number of !includes already. I do prefer duplication specifically
for Xen vs. QEMU however.
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-10 14:27 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-10 14:27 UTC (permalink / raw)
To: Jordan Justen, Anthony PERARD, devel
Cc: xen-devel, Julien Grall, Ard Biesheuvel
On 04/10/19 11:48, Jordan Justen wrote:
> On 2019-04-09 04:08:15, Anthony PERARD wrote:
>> This is a copy of OvmfX64, removing VirtIO and some SMM.
>>
>> This new platform will be changed to make it works on two types of Xen
>> guest: HVM and PVH.
>>
>> Compare to OvmfX64, this patch:
>>
>> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
>> - removed: VirtioLib class resolution
>> - removed: all UEFI_DRIVER modules for virtio devices
>> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
>> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
>> - removed: Everything related to SMM_REQUIRE==true
>> - removed: Everything related to SECURE_BOOT_ENABLE==true
>> - removed: Everything related to TPM2_ENABLE==true
>> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
>> - changed: default FD_SIZE_IN_KB to 2M.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
>
> I guess we all want our name to be first :), but OvmfXen seems more
> like the pattern that edk2 uses when making sub-platforms.
>
> Also, in some cases we've used !ifdef type things to keep dsc and fdf
> files common. Would that not be workable here? Maybe it would get too
> ugly. :\
I've been happy with a similar Xen<->QEMU split under ArmVirtPkg.
Duplications in updates are usually not a huge burden, and keeping the
files separate has proved very helpful for determining
maintainer/reviewer/tester responsibility.
> It could help to prevent having to sync dsc changes across, and
> prevent changes from being omitted for Xen on accident.
True, but in my experience that's been the smaller problem. The larger
problem has been modifying Xen stuff in unintended ways (= regressing
Xen), because we can't test (or don't even notice) the Xen-side
implications of changes made to common source.
Personally I prefer another (DSC + FDF) pair under OvmfPkg (beyond the
three we already have) to another layer of (conditional?) includes. The
!if's that are being eliminated in this Xen-customized copy (i.e., in
this patch) are complex enough already :)
... It's not that I *generally* prefer duplication; as you say, we do
have a number of !includes already. I do prefer duplication specifically
for Xen vs. QEMU however.
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-10 16:27 ` Ard Biesheuvel
0 siblings, 0 replies; 168+ messages in thread
From: Ard Biesheuvel @ 2019-04-10 16:27 UTC (permalink / raw)
To: edk2-devel-groups-io, Laszlo Ersek
Cc: Anthony PERARD, Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On Wed, 10 Apr 2019 at 07:27, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 04/10/19 11:48, Jordan Justen wrote:
> > On 2019-04-09 04:08:15, Anthony PERARD wrote:
> >> This is a copy of OvmfX64, removing VirtIO and some SMM.
> >>
> >> This new platform will be changed to make it works on two types of Xen
> >> guest: HVM and PVH.
> >>
> >> Compare to OvmfX64, this patch:
> >>
> >> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
> >> - removed: VirtioLib class resolution
> >> - removed: all UEFI_DRIVER modules for virtio devices
> >> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
> >> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
> >> - removed: Everything related to SMM_REQUIRE==true
> >> - removed: Everything related to SECURE_BOOT_ENABLE==true
> >> - removed: Everything related to TPM2_ENABLE==true
> >> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
> >> - changed: default FD_SIZE_IN_KB to 2M.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >> ---
> >> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
> >
> > I guess we all want our name to be first :), but OvmfXen seems more
> > like the pattern that edk2 uses when making sub-platforms.
> >
> > Also, in some cases we've used !ifdef type things to keep dsc and fdf
> > files common. Would that not be workable here? Maybe it would get too
> > ugly. :\
>
> I've been happy with a similar Xen<->QEMU split under ArmVirtPkg.
> Duplications in updates are usually not a huge burden, and keeping the
> files separate has proved very helpful for determining
> maintainer/reviewer/tester responsibility.
>
> > It could help to prevent having to sync dsc changes across, and
> > prevent changes from being omitted for Xen on accident.
>
> True, but in my experience that's been the smaller problem. The larger
> problem has been modifying Xen stuff in unintended ways (= regressing
> Xen), because we can't test (or don't even notice) the Xen-side
> implications of changes made to common source.
>
> Personally I prefer another (DSC + FDF) pair under OvmfPkg (beyond the
> three we already have) to another layer of (conditional?) includes. The
> !if's that are being eliminated in this Xen-customized copy (i.e., in
> this patch) are complex enough already :)
>
> ... It's not that I *generally* prefer duplication; as you say, we do
> have a number of !includes already. I do prefer duplication specifically
> for Xen vs. QEMU however.
>
+1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-10 16:27 ` Ard Biesheuvel
0 siblings, 0 replies; 168+ messages in thread
From: Ard Biesheuvel @ 2019-04-10 16:27 UTC (permalink / raw)
To: edk2-devel-groups-io, Laszlo Ersek
Cc: Anthony PERARD, Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On Wed, 10 Apr 2019 at 07:27, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 04/10/19 11:48, Jordan Justen wrote:
> > On 2019-04-09 04:08:15, Anthony PERARD wrote:
> >> This is a copy of OvmfX64, removing VirtIO and some SMM.
> >>
> >> This new platform will be changed to make it works on two types of Xen
> >> guest: HVM and PVH.
> >>
> >> Compare to OvmfX64, this patch:
> >>
> >> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
> >> - removed: VirtioLib class resolution
> >> - removed: all UEFI_DRIVER modules for virtio devices
> >> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
> >> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
> >> - removed: Everything related to SMM_REQUIRE==true
> >> - removed: Everything related to SECURE_BOOT_ENABLE==true
> >> - removed: Everything related to TPM2_ENABLE==true
> >> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
> >> - changed: default FD_SIZE_IN_KB to 2M.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >> ---
> >> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
> >
> > I guess we all want our name to be first :), but OvmfXen seems more
> > like the pattern that edk2 uses when making sub-platforms.
> >
> > Also, in some cases we've used !ifdef type things to keep dsc and fdf
> > files common. Would that not be workable here? Maybe it would get too
> > ugly. :\
>
> I've been happy with a similar Xen<->QEMU split under ArmVirtPkg.
> Duplications in updates are usually not a huge burden, and keeping the
> files separate has proved very helpful for determining
> maintainer/reviewer/tester responsibility.
>
> > It could help to prevent having to sync dsc changes across, and
> > prevent changes from being omitted for Xen on accident.
>
> True, but in my experience that's been the smaller problem. The larger
> problem has been modifying Xen stuff in unintended ways (= regressing
> Xen), because we can't test (or don't even notice) the Xen-side
> implications of changes made to common source.
>
> Personally I prefer another (DSC + FDF) pair under OvmfPkg (beyond the
> three we already have) to another layer of (conditional?) includes. The
> !if's that are being eliminated in this Xen-customized copy (i.e., in
> this patch) are complex enough already :)
>
> ... It's not that I *generally* prefer duplication; as you say, we do
> have a number of !includes already. I do prefer duplication specifically
> for Xen vs. QEMU however.
>
+1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-10 18:37 ` Jordan Justen
0 siblings, 0 replies; 168+ messages in thread
From: Jordan Justen @ 2019-04-10 18:37 UTC (permalink / raw)
To: Anthony PERARD, Laszlo Ersek, devel
Cc: xen-devel, Julien Grall, Ard Biesheuvel
On 2019-04-10 07:27:15, Laszlo Ersek wrote:
> On 04/10/19 11:48, Jordan Justen wrote:
> > On 2019-04-09 04:08:15, Anthony PERARD wrote:
> >> This is a copy of OvmfX64, removing VirtIO and some SMM.
> >>
> >> This new platform will be changed to make it works on two types of Xen
> >> guest: HVM and PVH.
> >>
> >> Compare to OvmfX64, this patch:
> >>
> >> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
> >> - removed: VirtioLib class resolution
> >> - removed: all UEFI_DRIVER modules for virtio devices
> >> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
> >> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
> >> - removed: Everything related to SMM_REQUIRE==true
> >> - removed: Everything related to SECURE_BOOT_ENABLE==true
> >> - removed: Everything related to TPM2_ENABLE==true
> >> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
> >> - changed: default FD_SIZE_IN_KB to 2M.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >> ---
> >> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
> >
> > I guess we all want our name to be first :), but OvmfXen seems more
> > like the pattern that edk2 uses when making sub-platforms.
For example: ArmVirtPkg/ArmVirtXen.dsc
> >
> > Also, in some cases we've used !ifdef type things to keep dsc and fdf
> > files common. Would that not be workable here? Maybe it would get too
> > ugly. :\
>
> I've been happy with a similar Xen<->QEMU split under ArmVirtPkg.
> Duplications in updates are usually not a huge burden, and keeping the
> files separate has proved very helpful for determining
> maintainer/reviewer/tester responsibility.
>
> > It could help to prevent having to sync dsc changes across, and
> > prevent changes from being omitted for Xen on accident.
>
> True, but in my experience that's been the smaller problem. The larger
> problem has been modifying Xen stuff in unintended ways (= regressing
> Xen), because we can't test (or don't even notice) the Xen-side
> implications of changes made to common source.
Does that mean you avoid changing ArmVirtXen.dsc entirely, or you try
to update it when it seems likely to not cause trouble? I could see
unintended breakage either way.
Anyway, it sounds like it's generally working out okay with
ArmVirtXen, so it seems okay to follow that under OvmfPkg.
-Jordan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-10 18:37 ` Jordan Justen
0 siblings, 0 replies; 168+ messages in thread
From: Jordan Justen @ 2019-04-10 18:37 UTC (permalink / raw)
To: Anthony PERARD, Laszlo Ersek, devel
Cc: xen-devel, Julien Grall, Ard Biesheuvel
On 2019-04-10 07:27:15, Laszlo Ersek wrote:
> On 04/10/19 11:48, Jordan Justen wrote:
> > On 2019-04-09 04:08:15, Anthony PERARD wrote:
> >> This is a copy of OvmfX64, removing VirtIO and some SMM.
> >>
> >> This new platform will be changed to make it works on two types of Xen
> >> guest: HVM and PVH.
> >>
> >> Compare to OvmfX64, this patch:
> >>
> >> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
> >> - removed: VirtioLib class resolution
> >> - removed: all UEFI_DRIVER modules for virtio devices
> >> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
> >> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
> >> - removed: Everything related to SMM_REQUIRE==true
> >> - removed: Everything related to SECURE_BOOT_ENABLE==true
> >> - removed: Everything related to TPM2_ENABLE==true
> >> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
> >> - changed: default FD_SIZE_IN_KB to 2M.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >> ---
> >> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
> >
> > I guess we all want our name to be first :), but OvmfXen seems more
> > like the pattern that edk2 uses when making sub-platforms.
For example: ArmVirtPkg/ArmVirtXen.dsc
> >
> > Also, in some cases we've used !ifdef type things to keep dsc and fdf
> > files common. Would that not be workable here? Maybe it would get too
> > ugly. :\
>
> I've been happy with a similar Xen<->QEMU split under ArmVirtPkg.
> Duplications in updates are usually not a huge burden, and keeping the
> files separate has proved very helpful for determining
> maintainer/reviewer/tester responsibility.
>
> > It could help to prevent having to sync dsc changes across, and
> > prevent changes from being omitted for Xen on accident.
>
> True, but in my experience that's been the smaller problem. The larger
> problem has been modifying Xen stuff in unintended ways (= regressing
> Xen), because we can't test (or don't even notice) the Xen-side
> implications of changes made to common source.
Does that mean you avoid changing ArmVirtXen.dsc entirely, or you try
to update it when it seems likely to not cause trouble? I could see
unintended breakage either way.
Anyway, it sounds like it's generally working out okay with
ArmVirtXen, so it seems okay to follow that under OvmfPkg.
-Jordan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-11 7:34 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 7:34 UTC (permalink / raw)
To: Jordan Justen, Anthony PERARD, devel
Cc: xen-devel, Julien Grall, Ard Biesheuvel
On 04/10/19 20:37, Jordan Justen wrote:
> On 2019-04-10 07:27:15, Laszlo Ersek wrote:
>> On 04/10/19 11:48, Jordan Justen wrote:
>>> On 2019-04-09 04:08:15, Anthony PERARD wrote:
>>>> This is a copy of OvmfX64, removing VirtIO and some SMM.
>>>>
>>>> This new platform will be changed to make it works on two types of Xen
>>>> guest: HVM and PVH.
>>>>
>>>> Compare to OvmfX64, this patch:
>>>>
>>>> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
>>>> - removed: VirtioLib class resolution
>>>> - removed: all UEFI_DRIVER modules for virtio devices
>>>> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
>>>> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
>>>> - removed: Everything related to SMM_REQUIRE==true
>>>> - removed: Everything related to SECURE_BOOT_ENABLE==true
>>>> - removed: Everything related to TPM2_ENABLE==true
>>>> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
>>>> - changed: default FD_SIZE_IN_KB to 2M.
>>>>
>>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>>> ---
>>>> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
>>>
>>> I guess we all want our name to be first :), but OvmfXen seems more
>>> like the pattern that edk2 uses when making sub-platforms.
>
> For example: ArmVirtPkg/ArmVirtXen.dsc
Right, we all agree on this.
>
>>>
>>> Also, in some cases we've used !ifdef type things to keep dsc and fdf
>>> files common. Would that not be workable here? Maybe it would get too
>>> ugly. :\
>>
>> I've been happy with a similar Xen<->QEMU split under ArmVirtPkg.
>> Duplications in updates are usually not a huge burden, and keeping the
>> files separate has proved very helpful for determining
>> maintainer/reviewer/tester responsibility.
>>
>>> It could help to prevent having to sync dsc changes across, and
>>> prevent changes from being omitted for Xen on accident.
>>
>> True, but in my experience that's been the smaller problem. The larger
>> problem has been modifying Xen stuff in unintended ways (= regressing
>> Xen), because we can't test (or don't even notice) the Xen-side
>> implications of changes made to common source.
>
> Does that mean you avoid changing ArmVirtXen.dsc entirely, or you try
> to update it when it seems likely to not cause trouble? I could see
> unintended breakage either way.
Under ArmVirtPkg, we have three platforms: ArmVirtQemu,
ArmVirtQemuKernel, and ArmVirtXen. All of these have separate DSC files.
All include ArmVirt.dsc.inc.
In addition, all three have FDF files, but ArmVirtQemu and
ArmVirtQemuKernel share (include) ArmVirtQemuFvMain.fdf.inc.
ArmVirtQemu and ArmVirtQemuKernel differ in that the latter is supposed
to be launched with "-kernel" on QEMU, not via pflash.
I primarily care about ArmVirtQemu. I always start modifications there.
Then I evaluate whether the change makes sense for ArmVirtQemuKernel,
and rely on Ard to confirm that. ArmVirtXen is the last thought for me,
and I try to make a "best effort" to figure out the impact.
When I'm stongly in doubt re: Xen, I avoid modifying ArmVirtXen. When I
sort of suspect that modifying Xen is valid/necessary, then I (a) either
modify ArmVirtXen explicitly, or (b) modify ArmVirt.dsc.inc *AND* talk
about Xen explicitly in the commit message, and/or the cover letter.
Case (b) is quite rare. When it happens, it usually follows immediately
(a) -- I might change ArmVirtXen, and then realize something is now
shared between Xen and QEMU. It's then a separate decision whether I
actually want to merge that thing into ArmVirt.dsc.inc -- sometimes
that's not the best decision (exactly because it increases shared review
responsibility for the future).
In both case (a) and (b), I CC the Xen reviewers. The point is that
"Xen" is mentioned somewhere explicitly (diffstat or commit message).
This lets us decide more clearly whether Xen reviewers should
participate -- when they don't have to, that saves us all time, and so
when they *do* need to, their responsibility is both big and clear.
If, for QEMU feature development or bugfixing, we kept modifying files
that were by default processed in Xen builds too, then Xen people would
be bombarded with review requests they'd rather ignore. Their attention
would wane and they'd miss (or greatly delay) the reviews when they
should indeed follow up (and hopefully quickly).
It's not a 100% "scientific" workflow, and you are right that both
approaches can cause issues by omission. In my experience the split
tends to be safer (and easier on human resources), in practice.
> Anyway, it sounds like it's generally working out okay with
> ArmVirtXen, so it seems okay to follow that under OvmfPkg.
Thanks!
Laszlo
>
> -Jordan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
@ 2019-04-11 7:34 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 7:34 UTC (permalink / raw)
To: Jordan Justen, Anthony PERARD, devel
Cc: xen-devel, Julien Grall, Ard Biesheuvel
On 04/10/19 20:37, Jordan Justen wrote:
> On 2019-04-10 07:27:15, Laszlo Ersek wrote:
>> On 04/10/19 11:48, Jordan Justen wrote:
>>> On 2019-04-09 04:08:15, Anthony PERARD wrote:
>>>> This is a copy of OvmfX64, removing VirtIO and some SMM.
>>>>
>>>> This new platform will be changed to make it works on two types of Xen
>>>> guest: HVM and PVH.
>>>>
>>>> Compare to OvmfX64, this patch:
>>>>
>>>> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
>>>> - removed: VirtioLib class resolution
>>>> - removed: all UEFI_DRIVER modules for virtio devices
>>>> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
>>>> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
>>>> - removed: Everything related to SMM_REQUIRE==true
>>>> - removed: Everything related to SECURE_BOOT_ENABLE==true
>>>> - removed: Everything related to TPM2_ENABLE==true
>>>> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
>>>> - changed: default FD_SIZE_IN_KB to 2M.
>>>>
>>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>>> ---
>>>> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
>>>
>>> I guess we all want our name to be first :), but OvmfXen seems more
>>> like the pattern that edk2 uses when making sub-platforms.
>
> For example: ArmVirtPkg/ArmVirtXen.dsc
Right, we all agree on this.
>
>>>
>>> Also, in some cases we've used !ifdef type things to keep dsc and fdf
>>> files common. Would that not be workable here? Maybe it would get too
>>> ugly. :\
>>
>> I've been happy with a similar Xen<->QEMU split under ArmVirtPkg.
>> Duplications in updates are usually not a huge burden, and keeping the
>> files separate has proved very helpful for determining
>> maintainer/reviewer/tester responsibility.
>>
>>> It could help to prevent having to sync dsc changes across, and
>>> prevent changes from being omitted for Xen on accident.
>>
>> True, but in my experience that's been the smaller problem. The larger
>> problem has been modifying Xen stuff in unintended ways (= regressing
>> Xen), because we can't test (or don't even notice) the Xen-side
>> implications of changes made to common source.
>
> Does that mean you avoid changing ArmVirtXen.dsc entirely, or you try
> to update it when it seems likely to not cause trouble? I could see
> unintended breakage either way.
Under ArmVirtPkg, we have three platforms: ArmVirtQemu,
ArmVirtQemuKernel, and ArmVirtXen. All of these have separate DSC files.
All include ArmVirt.dsc.inc.
In addition, all three have FDF files, but ArmVirtQemu and
ArmVirtQemuKernel share (include) ArmVirtQemuFvMain.fdf.inc.
ArmVirtQemu and ArmVirtQemuKernel differ in that the latter is supposed
to be launched with "-kernel" on QEMU, not via pflash.
I primarily care about ArmVirtQemu. I always start modifications there.
Then I evaluate whether the change makes sense for ArmVirtQemuKernel,
and rely on Ard to confirm that. ArmVirtXen is the last thought for me,
and I try to make a "best effort" to figure out the impact.
When I'm stongly in doubt re: Xen, I avoid modifying ArmVirtXen. When I
sort of suspect that modifying Xen is valid/necessary, then I (a) either
modify ArmVirtXen explicitly, or (b) modify ArmVirt.dsc.inc *AND* talk
about Xen explicitly in the commit message, and/or the cover letter.
Case (b) is quite rare. When it happens, it usually follows immediately
(a) -- I might change ArmVirtXen, and then realize something is now
shared between Xen and QEMU. It's then a separate decision whether I
actually want to merge that thing into ArmVirt.dsc.inc -- sometimes
that's not the best decision (exactly because it increases shared review
responsibility for the future).
In both case (a) and (b), I CC the Xen reviewers. The point is that
"Xen" is mentioned somewhere explicitly (diffstat or commit message).
This lets us decide more clearly whether Xen reviewers should
participate -- when they don't have to, that saves us all time, and so
when they *do* need to, their responsibility is both big and clear.
If, for QEMU feature development or bugfixing, we kept modifying files
that were by default processed in Xen builds too, then Xen people would
be bombarded with review requests they'd rather ignore. Their attention
would wane and they'd miss (or greatly delay) the reviews when they
should indeed follow up (and hopefully quickly).
It's not a 100% "scientific" workflow, and you are right that both
approaches can cause issues by omission. In my experience the split
tends to be safer (and easier on human resources), in practice.
> Anyway, it sounds like it's generally working out okay with
> ArmVirtXen, so it seems okay to follow that under OvmfPkg.
Thanks!
Laszlo
>
> -Jordan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 03/31] OvmfPkg: Introduce XenResetVector
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Copy of OvmfPkg/ResetVector, with one changes:
- SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)
Xen copies the OVMF code to RAM, there is no need to disable cache.
This new module will later be modified to add a new entry point, more
detail in a following commit "OvmfPkg/XenResetVector: Add new entry point
for Xen PVH"
Value FILE_GUID of XenResetVector have not changed compare to ResetVector
because it is a special value.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenOvmf.dsc | 2 +-
OvmfPkg/XenOvmf.fdf | 2 +-
OvmfPkg/{ResetVector/ResetVector.inf => XenResetVector/XenResetVector.inf} | 5 +++--
{UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia16/Real16ToFlat32.asm | 4 +++-
OvmfPkg/{ResetVector => XenResetVector}/Ia32/PageTables64.asm | 2 ++
OvmfPkg/{ResetVector/ResetVector.nasmb => XenResetVector/XenResetVector.nasmb} | 2 ++
6 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index bfe9190735..6161133fa8 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -503,7 +503,7 @@ [PcdsDynamicDefault]
#
################################################################################
[Components]
- OvmfPkg/ResetVector/ResetVector.inf
+ OvmfPkg/XenResetVector/XenResetVector.inf
#
# SEC Phase modules
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 612ffb2e01..292cf4b492 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -124,7 +124,7 @@ [FV.SECFV]
#
INF OvmfPkg/Sec/SecMain.inf
-INF RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
+INF RuleOverride=RESET_VECTOR OvmfPkg/XenResetVector/XenResetVector.inf
################################################################################
[FV.PEIFV]
diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/XenResetVector/XenResetVector.inf
similarity index 88%
copy from OvmfPkg/ResetVector/ResetVector.inf
copy to OvmfPkg/XenResetVector/XenResetVector.inf
index d1e5d4d9bd..5c05f02285 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/XenResetVector/XenResetVector.inf
@@ -2,6 +2,7 @@
# Reset Vector
#
# Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -14,7 +15,7 @@
[Defines]
INF_VERSION = 0x00010005
- BASE_NAME = ResetVector
+ BASE_NAME = XenResetVector
FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
MODULE_TYPE = SEC
VERSION_STRING = 1.1
@@ -26,7 +27,7 @@ [Defines]
#
[Sources]
- ResetVector.nasmb
+ XenResetVector.nasmb
[Packages]
OvmfPkg/OvmfPkg.dec
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
similarity index 94%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
copy to OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
index bc68c8dd74..e22e92c8a6 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
+++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
@@ -3,6 +3,8 @@
; Transition from 16 bit real mode into 32 bit flat protected mode
;
; Copyright (c) 2008 - 2010, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
@@ -13,7 +15,7 @@
;
;------------------------------------------------------------------------------
-%define SEC_DEFAULT_CR0 0x40000023
+%define SEC_DEFAULT_CR0 0x00000023
%define SEC_DEFAULT_CR4 0x640
BITS 16
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
similarity index 95%
copy from OvmfPkg/ResetVector/Ia32/PageTables64.asm
copy to OvmfPkg/XenResetVector/Ia32/PageTables64.asm
index db1590aedd..ded466031b 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
@@ -3,6 +3,8 @@
; Sets the CR3 register for 64-bit paging
;
; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
similarity index 94%
copy from OvmfPkg/ResetVector/ResetVector.nasmb
copy to OvmfPkg/XenResetVector/XenResetVector.nasmb
index 29cbad3677..49f2bab001 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
@@ -3,6 +3,8 @@
; This file includes all other code files to assemble the reset vector code
;
; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 03/31] OvmfPkg: Introduce XenResetVector
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Copy of OvmfPkg/ResetVector, with one changes:
- SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)
Xen copies the OVMF code to RAM, there is no need to disable cache.
This new module will later be modified to add a new entry point, more
detail in a following commit "OvmfPkg/XenResetVector: Add new entry point
for Xen PVH"
Value FILE_GUID of XenResetVector have not changed compare to ResetVector
because it is a special value.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenOvmf.dsc | 2 +-
OvmfPkg/XenOvmf.fdf | 2 +-
OvmfPkg/{ResetVector/ResetVector.inf => XenResetVector/XenResetVector.inf} | 5 +++--
{UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia16/Real16ToFlat32.asm | 4 +++-
OvmfPkg/{ResetVector => XenResetVector}/Ia32/PageTables64.asm | 2 ++
OvmfPkg/{ResetVector/ResetVector.nasmb => XenResetVector/XenResetVector.nasmb} | 2 ++
6 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index bfe9190735..6161133fa8 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -503,7 +503,7 @@ [PcdsDynamicDefault]
#
################################################################################
[Components]
- OvmfPkg/ResetVector/ResetVector.inf
+ OvmfPkg/XenResetVector/XenResetVector.inf
#
# SEC Phase modules
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 612ffb2e01..292cf4b492 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -124,7 +124,7 @@ [FV.SECFV]
#
INF OvmfPkg/Sec/SecMain.inf
-INF RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
+INF RuleOverride=RESET_VECTOR OvmfPkg/XenResetVector/XenResetVector.inf
################################################################################
[FV.PEIFV]
diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/XenResetVector/XenResetVector.inf
similarity index 88%
copy from OvmfPkg/ResetVector/ResetVector.inf
copy to OvmfPkg/XenResetVector/XenResetVector.inf
index d1e5d4d9bd..5c05f02285 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/XenResetVector/XenResetVector.inf
@@ -2,6 +2,7 @@
# Reset Vector
#
# Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -14,7 +15,7 @@
[Defines]
INF_VERSION = 0x00010005
- BASE_NAME = ResetVector
+ BASE_NAME = XenResetVector
FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
MODULE_TYPE = SEC
VERSION_STRING = 1.1
@@ -26,7 +27,7 @@ [Defines]
#
[Sources]
- ResetVector.nasmb
+ XenResetVector.nasmb
[Packages]
OvmfPkg/OvmfPkg.dec
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
similarity index 94%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
copy to OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
index bc68c8dd74..e22e92c8a6 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
+++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
@@ -3,6 +3,8 @@
; Transition from 16 bit real mode into 32 bit flat protected mode
;
; Copyright (c) 2008 - 2010, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
@@ -13,7 +15,7 @@
;
;------------------------------------------------------------------------------
-%define SEC_DEFAULT_CR0 0x40000023
+%define SEC_DEFAULT_CR0 0x00000023
%define SEC_DEFAULT_CR4 0x640
BITS 16
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
similarity index 95%
copy from OvmfPkg/ResetVector/Ia32/PageTables64.asm
copy to OvmfPkg/XenResetVector/Ia32/PageTables64.asm
index db1590aedd..ded466031b 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
@@ -3,6 +3,8 @@
; Sets the CR3 register for 64-bit paging
;
; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
similarity index 94%
copy from OvmfPkg/ResetVector/ResetVector.nasmb
copy to OvmfPkg/XenResetVector/XenResetVector.nasmb
index 29cbad3677..49f2bab001 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
@@ -3,6 +3,8 @@
; This file includes all other code files to assemble the reset vector code
;
; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 03/31] OvmfPkg: Introduce XenResetVector
@ 2019-04-10 9:46 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-10 9:46 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Copy of OvmfPkg/ResetVector, with one changes:
> - SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)
>
> Xen copies the OVMF code to RAM, there is no need to disable cache.
>
> This new module will later be modified to add a new entry point, more
> detail in a following commit "OvmfPkg/XenResetVector: Add new entry point
> for Xen PVH"
OK. The present patch in itself is a bit too heavy (two files are copied
for no apparent reason -- they don't see any real changes here), so one
might be tempted to suggest "create XenResetVector.inf in the currently
existing directory, for sharing more source code". But the above
paragraph explains why a full copy is justified / desirable.
> Value FILE_GUID of XenResetVector have not changed compare to ResetVector
> because it is a special value.
(1) Yes, please mention "gEfiFirmwareVolumeTopFileGuid" here.
With that commit message update:
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks,
Laszlo
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenOvmf.dsc | 2 +-
> OvmfPkg/XenOvmf.fdf | 2 +-
> OvmfPkg/{ResetVector/ResetVector.inf => XenResetVector/XenResetVector.inf} | 5 +++--
> {UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia16/Real16ToFlat32.asm | 4 +++-
> OvmfPkg/{ResetVector => XenResetVector}/Ia32/PageTables64.asm | 2 ++
> OvmfPkg/{ResetVector/ResetVector.nasmb => XenResetVector/XenResetVector.nasmb} | 2 ++
> 6 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index bfe9190735..6161133fa8 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -503,7 +503,7 @@ [PcdsDynamicDefault]
> #
> ################################################################################
> [Components]
> - OvmfPkg/ResetVector/ResetVector.inf
> + OvmfPkg/XenResetVector/XenResetVector.inf
>
> #
> # SEC Phase modules
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index 612ffb2e01..292cf4b492 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -124,7 +124,7 @@ [FV.SECFV]
> #
> INF OvmfPkg/Sec/SecMain.inf
>
> -INF RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
> +INF RuleOverride=RESET_VECTOR OvmfPkg/XenResetVector/XenResetVector.inf
>
> ################################################################################
> [FV.PEIFV]
> diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/XenResetVector/XenResetVector.inf
> similarity index 88%
> copy from OvmfPkg/ResetVector/ResetVector.inf
> copy to OvmfPkg/XenResetVector/XenResetVector.inf
> index d1e5d4d9bd..5c05f02285 100644
> --- a/OvmfPkg/ResetVector/ResetVector.inf
> +++ b/OvmfPkg/XenResetVector/XenResetVector.inf
> @@ -2,6 +2,7 @@
> # Reset Vector
> #
> # Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> @@ -14,7 +15,7 @@
>
> [Defines]
> INF_VERSION = 0x00010005
> - BASE_NAME = ResetVector
> + BASE_NAME = XenResetVector
> FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
> MODULE_TYPE = SEC
> VERSION_STRING = 1.1
> @@ -26,7 +27,7 @@ [Defines]
> #
>
> [Sources]
> - ResetVector.nasmb
> + XenResetVector.nasmb
>
> [Packages]
> OvmfPkg/OvmfPkg.dec
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> similarity index 94%
> copy from UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
> copy to OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> index bc68c8dd74..e22e92c8a6 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
> +++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> @@ -3,6 +3,8 @@
> ; Transition from 16 bit real mode into 32 bit flat protected mode
> ;
> ; Copyright (c) 2008 - 2010, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
> @@ -13,7 +15,7 @@
> ;
> ;------------------------------------------------------------------------------
>
> -%define SEC_DEFAULT_CR0 0x40000023
> +%define SEC_DEFAULT_CR0 0x00000023
> %define SEC_DEFAULT_CR4 0x640
>
> BITS 16
> diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> similarity index 95%
> copy from OvmfPkg/ResetVector/Ia32/PageTables64.asm
> copy to OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> index db1590aedd..ded466031b 100644
> --- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> +++ b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> @@ -3,6 +3,8 @@
> ; Sets the CR3 register for 64-bit paging
> ;
> ; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
> diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> similarity index 94%
> copy from OvmfPkg/ResetVector/ResetVector.nasmb
> copy to OvmfPkg/XenResetVector/XenResetVector.nasmb
> index 29cbad3677..49f2bab001 100644
> --- a/OvmfPkg/ResetVector/ResetVector.nasmb
> +++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> @@ -3,6 +3,8 @@
> ; This file includes all other code files to assemble the reset vector code
> ;
> ; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 03/31] OvmfPkg: Introduce XenResetVector
@ 2019-04-10 9:46 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-10 9:46 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Copy of OvmfPkg/ResetVector, with one changes:
> - SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)
>
> Xen copies the OVMF code to RAM, there is no need to disable cache.
>
> This new module will later be modified to add a new entry point, more
> detail in a following commit "OvmfPkg/XenResetVector: Add new entry point
> for Xen PVH"
OK. The present patch in itself is a bit too heavy (two files are copied
for no apparent reason -- they don't see any real changes here), so one
might be tempted to suggest "create XenResetVector.inf in the currently
existing directory, for sharing more source code". But the above
paragraph explains why a full copy is justified / desirable.
> Value FILE_GUID of XenResetVector have not changed compare to ResetVector
> because it is a special value.
(1) Yes, please mention "gEfiFirmwareVolumeTopFileGuid" here.
With that commit message update:
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks,
Laszlo
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenOvmf.dsc | 2 +-
> OvmfPkg/XenOvmf.fdf | 2 +-
> OvmfPkg/{ResetVector/ResetVector.inf => XenResetVector/XenResetVector.inf} | 5 +++--
> {UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia16/Real16ToFlat32.asm | 4 +++-
> OvmfPkg/{ResetVector => XenResetVector}/Ia32/PageTables64.asm | 2 ++
> OvmfPkg/{ResetVector/ResetVector.nasmb => XenResetVector/XenResetVector.nasmb} | 2 ++
> 6 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index bfe9190735..6161133fa8 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -503,7 +503,7 @@ [PcdsDynamicDefault]
> #
> ################################################################################
> [Components]
> - OvmfPkg/ResetVector/ResetVector.inf
> + OvmfPkg/XenResetVector/XenResetVector.inf
>
> #
> # SEC Phase modules
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index 612ffb2e01..292cf4b492 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -124,7 +124,7 @@ [FV.SECFV]
> #
> INF OvmfPkg/Sec/SecMain.inf
>
> -INF RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
> +INF RuleOverride=RESET_VECTOR OvmfPkg/XenResetVector/XenResetVector.inf
>
> ################################################################################
> [FV.PEIFV]
> diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/XenResetVector/XenResetVector.inf
> similarity index 88%
> copy from OvmfPkg/ResetVector/ResetVector.inf
> copy to OvmfPkg/XenResetVector/XenResetVector.inf
> index d1e5d4d9bd..5c05f02285 100644
> --- a/OvmfPkg/ResetVector/ResetVector.inf
> +++ b/OvmfPkg/XenResetVector/XenResetVector.inf
> @@ -2,6 +2,7 @@
> # Reset Vector
> #
> # Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> @@ -14,7 +15,7 @@
>
> [Defines]
> INF_VERSION = 0x00010005
> - BASE_NAME = ResetVector
> + BASE_NAME = XenResetVector
> FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
> MODULE_TYPE = SEC
> VERSION_STRING = 1.1
> @@ -26,7 +27,7 @@ [Defines]
> #
>
> [Sources]
> - ResetVector.nasmb
> + XenResetVector.nasmb
>
> [Packages]
> OvmfPkg/OvmfPkg.dec
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> similarity index 94%
> copy from UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
> copy to OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> index bc68c8dd74..e22e92c8a6 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
> +++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> @@ -3,6 +3,8 @@
> ; Transition from 16 bit real mode into 32 bit flat protected mode
> ;
> ; Copyright (c) 2008 - 2010, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
> @@ -13,7 +15,7 @@
> ;
> ;------------------------------------------------------------------------------
>
> -%define SEC_DEFAULT_CR0 0x40000023
> +%define SEC_DEFAULT_CR0 0x00000023
> %define SEC_DEFAULT_CR4 0x640
>
> BITS 16
> diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> similarity index 95%
> copy from OvmfPkg/ResetVector/Ia32/PageTables64.asm
> copy to OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> index db1590aedd..ded466031b 100644
> --- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> +++ b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> @@ -3,6 +3,8 @@
> ; Sets the CR3 register for 64-bit paging
> ;
> ; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
> diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> similarity index 94%
> copy from OvmfPkg/ResetVector/ResetVector.nasmb
> copy to OvmfPkg/XenResetVector/XenResetVector.nasmb
> index 29cbad3677..49f2bab001 100644
> --- a/OvmfPkg/ResetVector/ResetVector.nasmb
> +++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> @@ -3,6 +3,8 @@
> ; This file includes all other code files to assemble the reset vector code
> ;
> ; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 04/31] OvmfPkg: Introduce XenPlatformPei
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
A copy of OvmfPkg/PlatformPei without some of QEMU specific
initialization, Xen does not support QemuFwCfg.
This new module will be adjusted to accommodate Xen PVH.
fw_cfg dependents that have been removed, which are dynamically skipped
when running PlatformPei on Xen:
- GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
(experimental) "opt/ovmf/X-PciMmio64Mb" file
- GetFirstNonAddress(): honoring the hotplug DIMM area
("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO
aperture
- NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
PcdSetNxForStack are left constant FALSE (not set dynamically from
fw_cfg "opt/ovmf/PcdXxxx")
- MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
PcdCpuMaxLogicalProcessorNumber is used intact and
PcdCpuApInitTimeOutInMicroSeconds is never changed or used.
- InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
consulting "etc/system-states" via QemuFwCfgS3Enabled()).
- InstallFeatureControlCallback(): the feature control MSR is not set
from "etc/msr_feature_control"
(also removed FeatureControl.c as there is nothing been executed)
Also removed:
- SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
assumed FALSE) in PublishPeiMemory(),
- QemuInitializeRam() entirely,
Xen related changes:
- Have removed the module variable mXen, as it should be always true.
- Have the platform PEI initialization fails if Xen has not been
detected.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenOvmf.dsc | 2 +-
OvmfPkg/XenOvmf.fdf | 2 +-
OvmfPkg/{PlatformPei/PlatformPei.inf => XenPlatformPei/XenPlatformPei.inf} | 28 +-
OvmfPkg/{PlatformPei => XenPlatformPei}/Cmos.h | 2 +
OvmfPkg/{PlatformPei => XenPlatformPei}/Platform.h | 13 +-
OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.h | 0
OvmfPkg/{PlatformPei => XenPlatformPei}/AmdSev.c | 30 +-
OvmfPkg/{PlatformPei => XenPlatformPei}/ClearCache.c | 1 +
OvmfPkg/{PlatformPei => XenPlatformPei}/Cmos.c | 2 +
OvmfPkg/{PlatformPei => XenPlatformPei}/Fv.c | 26 +-
OvmfPkg/XenPlatformPei/MemDetect.c | 427 ++++++++++++++++++++
OvmfPkg/{PlatformPei => XenPlatformPei}/Platform.c | 246 +----------
OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.c | 8 +-
13 files changed, 453 insertions(+), 334 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 6161133fa8..7b8a1fdf6b 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -531,7 +531,7 @@ [Components]
}
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
- OvmfPkg/PlatformPei/PlatformPei.inf
+ OvmfPkg/XenPlatformPei/XenPlatformPei.inf
UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
UefiCpuPkg/CpuMpPei/CpuMpPei.inf
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 292cf4b492..295e30ca3f 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -158,7 +158,7 @@ [FV.PEIFV]
INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
-INF OvmfPkg/PlatformPei/PlatformPei.inf
+INF OvmfPkg/XenPlatformPei/XenPlatformPei.inf
INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
similarity index 69%
copy from OvmfPkg/PlatformPei/PlatformPei.inf
copy to OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 5c8dd0fe6d..c8d25c115f 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -3,6 +3,7 @@
#
# This module provides platform specific function to detect boot mode.
# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -16,11 +17,11 @@
[Defines]
INF_VERSION = 0x00010005
- BASE_NAME = PlatformPei
- FILE_GUID = 222c386d-5abc-4fb4-b124-fbb82488acf4
+ BASE_NAME = XenPlatformPei
+ FILE_GUID = f112a6ee-993a-4f0b-8295-e52029d9b4ba
MODULE_TYPE = PEIM
VERSION_STRING = 1.0
- ENTRY_POINT = InitializePlatform
+ ENTRY_POINT = InitializeXenPlatform
#
# The following information is for reference only and not required by the build tools.
@@ -33,7 +34,6 @@ [Sources]
ClearCache.c
Cmos.c
Cmos.h
- FeatureControl.c
Fv.c
MemDetect.c
Platform.c
@@ -62,10 +62,7 @@ [LibraryClasses]
PciLib
ResourcePublicationLib
PeiServicesLib
- PeiServicesTablePointerLib
PeimEntryPoint
- QemuFwCfgLib
- QemuFwCfgS3Lib
MtrrLib
MemEncryptSevLib
PcdLib
@@ -75,13 +72,8 @@ [Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
- gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
- gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
- gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
- gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
- gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize
@@ -89,31 +81,19 @@ [Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size
- gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
- gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
- gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
- gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
- gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
- gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
- gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
- gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds
- gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
[FixedPcd]
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
-[FeaturePcd]
- gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
-
[Ppis]
gEfiPeiMasterBootModePpiGuid
gEfiPeiMpServicesPpiGuid
diff --git a/OvmfPkg/PlatformPei/Cmos.h b/OvmfPkg/XenPlatformPei/Cmos.h
similarity index 92%
copy from OvmfPkg/PlatformPei/Cmos.h
copy to OvmfPkg/XenPlatformPei/Cmos.h
index 949f884c2c..defe677122 100644
--- a/OvmfPkg/PlatformPei/Cmos.h
+++ b/OvmfPkg/XenPlatformPei/Cmos.h
@@ -2,6 +2,8 @@
PC/AT CMOS access routines
Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
diff --git a/OvmfPkg/PlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
similarity index 88%
copy from OvmfPkg/PlatformPei/Platform.h
copy to OvmfPkg/XenPlatformPei/Platform.h
index b12a5c1f5f..6ccd5eb66c 100644
--- a/OvmfPkg/PlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -2,6 +2,8 @@
Platform PEI module include file.
Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -78,11 +80,6 @@ PeiFvInitialization (
VOID
);
-VOID
-InstallFeatureControlCallback (
- VOID
- );
-
VOID
InstallClearCacheCallback (
VOID
@@ -103,8 +100,6 @@ AmdSevInitialize (
VOID
);
-extern BOOLEAN mXen;
-
VOID
XenPublishRamRegions (
VOID
@@ -112,12 +107,8 @@ XenPublishRamRegions (
extern EFI_BOOT_MODE mBootMode;
-extern BOOLEAN mS3Supported;
-
extern UINT8 mPhysMemAddressWidth;
-extern UINT32 mMaxCpuCount;
-
extern UINT16 mHostBridgeDevId;
#endif // _PLATFORM_PEI_H_INCLUDED_
diff --git a/OvmfPkg/PlatformPei/Xen.h b/OvmfPkg/XenPlatformPei/Xen.h
similarity index 100%
copy from OvmfPkg/PlatformPei/Xen.h
copy to OvmfPkg/XenPlatformPei/Xen.h
diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/XenPlatformPei/AmdSev.c
similarity index 61%
copy from OvmfPkg/PlatformPei/AmdSev.c
copy to OvmfPkg/XenPlatformPei/AmdSev.c
index 2e14eaf8c3..1a1f46291f 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/XenPlatformPei/AmdSev.c
@@ -2,6 +2,7 @@
Initialize Secure Encrypted Virtualization (SEV) support
Copyright (c) 2017, Advanced Micro Devices. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
@@ -16,7 +17,6 @@
// The package level header files this module uses
//
#include <Library/DebugLib.h>
-#include <Library/HobLib.h>
#include <Library/MemEncryptSevLib.h>
#include <Library/PcdLib.h>
#include <PiPei.h>
@@ -67,32 +67,4 @@ AmdSevInitialize (
//
PcdStatus = PcdSet32S (PcdOptionRomImageVerificationPolicy, 0x4);
ASSERT_RETURN_ERROR (PcdStatus);
-
- //
- // When SMM is required, cover the pages containing the initial SMRAM Save
- // State Map with a memory allocation HOB:
- //
- // There's going to be a time interval between our decrypting those pages for
- // SMBASE relocation and re-encrypting the same pages after SMBASE
- // relocation. We shall ensure that the DXE phase stay away from those pages
- // until after re-encryption, in order to prevent an information leak to the
- // hypervisor.
- //
- if (FeaturePcdGet (PcdSmmSmramRequire) && (mBootMode != BOOT_ON_S3_RESUME)) {
- RETURN_STATUS LocateMapStatus;
- UINTN MapPagesBase;
- UINTN MapPagesCount;
-
- LocateMapStatus = MemEncryptSevLocateInitialSmramSaveStateMapPages (
- &MapPagesBase,
- &MapPagesCount
- );
- ASSERT_RETURN_ERROR (LocateMapStatus);
-
- BuildMemoryAllocationHob (
- MapPagesBase, // BaseAddress
- EFI_PAGES_TO_SIZE (MapPagesCount), // Length
- EfiBootServicesData // MemoryType
- );
- }
}
diff --git a/OvmfPkg/PlatformPei/ClearCache.c b/OvmfPkg/XenPlatformPei/ClearCache.c
similarity index 95%
copy from OvmfPkg/PlatformPei/ClearCache.c
copy to OvmfPkg/XenPlatformPei/ClearCache.c
index 7d15fd925c..78e22124e3 100644
--- a/OvmfPkg/PlatformPei/ClearCache.c
+++ b/OvmfPkg/XenPlatformPei/ClearCache.c
@@ -6,6 +6,7 @@
sake.
Copyright (C) 2018, Red Hat, Inc.
+ Copyright (c) 2019, Citrix Systems, Inc.
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
diff --git a/OvmfPkg/PlatformPei/Cmos.c b/OvmfPkg/XenPlatformPei/Cmos.c
similarity index 92%
copy from OvmfPkg/PlatformPei/Cmos.c
copy to OvmfPkg/XenPlatformPei/Cmos.c
index 48ed2cb8f4..174ec773ec 100644
--- a/OvmfPkg/PlatformPei/Cmos.c
+++ b/OvmfPkg/XenPlatformPei/Cmos.c
@@ -2,6 +2,8 @@
PC/AT CMOS access routines
Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
diff --git a/OvmfPkg/PlatformPei/Fv.c b/OvmfPkg/XenPlatformPei/Fv.c
similarity index 72%
copy from OvmfPkg/PlatformPei/Fv.c
copy to OvmfPkg/XenPlatformPei/Fv.c
index 248c585085..388e8768bf 100644
--- a/OvmfPkg/PlatformPei/Fv.c
+++ b/OvmfPkg/XenPlatformPei/Fv.c
@@ -2,6 +2,8 @@
Build FV related hobs for platform.
Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -32,8 +34,6 @@ PeiFvInitialization (
VOID
)
{
- BOOLEAN SecureS3Needed;
-
DEBUG ((EFI_D_INFO, "Platform PEI Firmware Volume Initialization\n"));
//
@@ -44,7 +44,7 @@ PeiFvInitialization (
BuildMemoryAllocationHob (
PcdGet32 (PcdOvmfPeiMemFvBase),
PcdGet32 (PcdOvmfPeiMemFvSize),
- mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
+ EfiBootServicesData
);
//
@@ -52,8 +52,6 @@ PeiFvInitialization (
//
BuildFvHob (PcdGet32 (PcdOvmfDxeMemFvBase), PcdGet32 (PcdOvmfDxeMemFvSize));
- SecureS3Needed = mS3Supported && FeaturePcdGet (PcdSmmSmramRequire);
-
//
// Create a memory allocation HOB for the DXE FV.
//
@@ -65,25 +63,9 @@ PeiFvInitialization (
BuildMemoryAllocationHob (
PcdGet32 (PcdOvmfDxeMemFvBase),
PcdGet32 (PcdOvmfDxeMemFvSize),
- SecureS3Needed ? EfiACPIMemoryNVS : EfiBootServicesData
+ EfiBootServicesData
);
- //
- // Additionally, said decompression will use temporary memory above the end
- // of DXEFV, so let's keep away the OS from there too.
- //
- if (SecureS3Needed) {
- UINT32 DxeMemFvEnd;
-
- DxeMemFvEnd = PcdGet32 (PcdOvmfDxeMemFvBase) +
- PcdGet32 (PcdOvmfDxeMemFvSize);
- BuildMemoryAllocationHob (
- DxeMemFvEnd,
- PcdGet32 (PcdOvmfDecompressionScratchEnd) - DxeMemFvEnd,
- EfiACPIMemoryNVS
- );
- }
-
//
// Let PEI know about the DXE FV so it can find the DXE Core
//
diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c b/OvmfPkg/XenPlatformPei/MemDetect.c
new file mode 100644
index 0000000000..db3d387d1c
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/MemDetect.c
@@ -0,0 +1,427 @@
+/**@file
+ Memory Detection for Virtual Machines.
+
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD License
+ which accompanies this distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+Module Name:
+
+ MemDetect.c
+
+**/
+
+//
+// The package level header files this module uses
+//
+#include <IndustryStandard/Q35MchIch9.h>
+#include <PiPei.h>
+
+//
+// The Library classes this module consumes
+//
+#include <Library/BaseLib.h>
+#include <Library/BaseMemoryLib.h>
+#include <Library/DebugLib.h>
+#include <Library/HobLib.h>
+#include <Library/IoLib.h>
+#include <Library/PcdLib.h>
+#include <Library/PciLib.h>
+#include <Library/PeimEntryPoint.h>
+#include <Library/ResourcePublicationLib.h>
+
+#include "Platform.h"
+#include "Cmos.h"
+
+UINT8 mPhysMemAddressWidth;
+
+STATIC UINT32 mS3AcpiReservedMemoryBase;
+STATIC UINT32 mS3AcpiReservedMemorySize;
+
+STATIC UINT16 mQ35TsegMbytes;
+
+VOID
+Q35TsegMbytesInitialization (
+ VOID
+ )
+{
+ UINT16 ExtendedTsegMbytes;
+ RETURN_STATUS PcdStatus;
+
+ if (mHostBridgeDevId != INTEL_Q35_MCH_DEVICE_ID) {
+ DEBUG ((
+ DEBUG_ERROR,
+ "%a: no TSEG (SMRAM) on host bridge DID=0x%04x; "
+ "only DID=0x%04x (Q35) is supported\n",
+ __FUNCTION__,
+ mHostBridgeDevId,
+ INTEL_Q35_MCH_DEVICE_ID
+ ));
+ ASSERT (FALSE);
+ CpuDeadLoop ();
+ }
+
+ //
+ // Check if QEMU offers an extended TSEG.
+ //
+ // This can be seen from writing MCH_EXT_TSEG_MB_QUERY to the MCH_EXT_TSEG_MB
+ // register, and reading back the register.
+ //
+ // On a QEMU machine type that does not offer an extended TSEG, the initial
+ // write overwrites whatever value a malicious guest OS may have placed in
+ // the (unimplemented) register, before entering S3 or rebooting.
+ // Subsequently, the read returns MCH_EXT_TSEG_MB_QUERY unchanged.
+ //
+ // On a QEMU machine type that offers an extended TSEG, the initial write
+ // triggers an update to the register. Subsequently, the value read back
+ // (which is guaranteed to differ from MCH_EXT_TSEG_MB_QUERY) tells us the
+ // number of megabytes.
+ //
+ PciWrite16 (DRAMC_REGISTER_Q35 (MCH_EXT_TSEG_MB), MCH_EXT_TSEG_MB_QUERY);
+ ExtendedTsegMbytes = PciRead16 (DRAMC_REGISTER_Q35 (MCH_EXT_TSEG_MB));
+ if (ExtendedTsegMbytes == MCH_EXT_TSEG_MB_QUERY) {
+ mQ35TsegMbytes = PcdGet16 (PcdQ35TsegMbytes);
+ return;
+ }
+
+ DEBUG ((
+ DEBUG_INFO,
+ "%a: QEMU offers an extended TSEG (%d MB)\n",
+ __FUNCTION__,
+ ExtendedTsegMbytes
+ ));
+ PcdStatus = PcdSet16S (PcdQ35TsegMbytes, ExtendedTsegMbytes);
+ ASSERT_RETURN_ERROR (PcdStatus);
+ mQ35TsegMbytes = ExtendedTsegMbytes;
+}
+
+
+UINT32
+GetSystemMemorySizeBelow4gb (
+ VOID
+ )
+{
+ UINT8 Cmos0x34;
+ UINT8 Cmos0x35;
+
+ //
+ // CMOS 0x34/0x35 specifies the system memory above 16 MB.
+ // * CMOS(0x35) is the high byte
+ // * CMOS(0x34) is the low byte
+ // * The size is specified in 64kb chunks
+ // * Since this is memory above 16MB, the 16MB must be added
+ // into the calculation to get the total memory size.
+ //
+
+ Cmos0x34 = (UINT8) CmosRead8 (0x34);
+ Cmos0x35 = (UINT8) CmosRead8 (0x35);
+
+ return (UINT32) (((UINTN)((Cmos0x35 << 8) + Cmos0x34) << 16) + SIZE_16MB);
+}
+
+
+STATIC
+UINT64
+GetSystemMemorySizeAbove4gb (
+ )
+{
+ UINT32 Size;
+ UINTN CmosIndex;
+
+ //
+ // CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
+ // * CMOS(0x5d) is the most significant size byte
+ // * CMOS(0x5c) is the middle size byte
+ // * CMOS(0x5b) is the least significant size byte
+ // * The size is specified in 64kb chunks
+ //
+
+ Size = 0;
+ for (CmosIndex = 0x5d; CmosIndex >= 0x5b; CmosIndex--) {
+ Size = (UINT32) (Size << 8) + (UINT32) CmosRead8 (CmosIndex);
+ }
+
+ return LShiftU64 (Size, 16);
+}
+
+
+/**
+ Return the highest address that DXE could possibly use, plus one.
+**/
+STATIC
+UINT64
+GetFirstNonAddress (
+ VOID
+ )
+{
+ UINT64 FirstNonAddress;
+ UINT64 Pci64Base, Pci64Size;
+ RETURN_STATUS PcdStatus;
+
+ FirstNonAddress = BASE_4GB + GetSystemMemorySizeAbove4gb ();
+
+ //
+ // If DXE is 32-bit, then we're done; PciBusDxe will degrade 64-bit MMIO
+ // resources to 32-bit anyway. See DegradeResource() in
+ // "PciResourceSupport.c".
+ //
+#ifdef MDE_CPU_IA32
+ if (!FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
+ return FirstNonAddress;
+ }
+#endif
+
+ //
+ // 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);
+
+ if (Pci64Size == 0) {
+ if (mBootMode != BOOT_ON_S3_RESUME) {
+ DEBUG ((EFI_D_INFO, "%a: disabling 64-bit PCI host aperture\n",
+ __FUNCTION__));
+ PcdStatus = PcdSet64S (PcdPciMmio64Size, 0);
+ ASSERT_RETURN_ERROR (PcdStatus);
+ }
+
+ //
+ // There's nothing more to do; the amount of memory above 4GB fully
+ // determines the highest address plus one. The memory hotplug area (see
+ // below) plays no role for the firmware in this case.
+ //
+ return FirstNonAddress;
+ }
+
+ //
+ // SeaBIOS aligns both boundaries of the 64-bit PCI host aperture to 1GB, so
+ // that the host can map it with 1GB hugepages. Follow suit.
+ //
+ Pci64Base = ALIGN_VALUE (FirstNonAddress, (UINT64)SIZE_1GB);
+ Pci64Size = ALIGN_VALUE (Pci64Size, (UINT64)SIZE_1GB);
+
+ //
+ // The 64-bit PCI host aperture should also be "naturally" aligned. The
+ // alignment is determined by rounding the size of the aperture down to the
+ // next smaller or equal power of two. That is, align the aperture by the
+ // largest BAR size that can fit into it.
+ //
+ Pci64Base = ALIGN_VALUE (Pci64Base, GetPowerOfTwo64 (Pci64Size));
+
+ if (mBootMode != BOOT_ON_S3_RESUME) {
+ //
+ // The core PciHostBridgeDxe driver will automatically add this range to
+ // the GCD memory space map through our PciHostBridgeLib instance; here we
+ // only need to set the PCDs.
+ //
+ PcdStatus = PcdSet64S (PcdPciMmio64Base, Pci64Base);
+ ASSERT_RETURN_ERROR (PcdStatus);
+ PcdStatus = PcdSet64S (PcdPciMmio64Size, Pci64Size);
+ ASSERT_RETURN_ERROR (PcdStatus);
+
+ DEBUG ((EFI_D_INFO, "%a: Pci64Base=0x%Lx Pci64Size=0x%Lx\n",
+ __FUNCTION__, Pci64Base, Pci64Size));
+ }
+
+ //
+ // The useful address space ends with the 64-bit PCI host aperture.
+ //
+ FirstNonAddress = Pci64Base + Pci64Size;
+ return FirstNonAddress;
+}
+
+
+/**
+ Initialize the mPhysMemAddressWidth variable, based on guest RAM size.
+**/
+VOID
+AddressWidthInitialization (
+ VOID
+ )
+{
+ UINT64 FirstNonAddress;
+
+ //
+ // As guest-physical memory size grows, the permanent PEI RAM requirements
+ // are dominated by the identity-mapping page tables built by the DXE IPL.
+ // The DXL IPL keys off of the physical address bits advertized in the CPU
+ // HOB. To conserve memory, we calculate the minimum address width here.
+ //
+ FirstNonAddress = GetFirstNonAddress ();
+ mPhysMemAddressWidth = (UINT8)HighBitSet64 (FirstNonAddress);
+
+ //
+ // If FirstNonAddress is not an integral power of two, then we need an
+ // additional bit.
+ //
+ if ((FirstNonAddress & (FirstNonAddress - 1)) != 0) {
+ ++mPhysMemAddressWidth;
+ }
+
+ //
+ // The minimum address width is 36 (covers up to and excluding 64 GB, which
+ // is the maximum for Ia32 + PAE). The theoretical architecture maximum for
+ // X64 long mode is 52 bits, but the DXE IPL clamps that down to 48 bits. We
+ // can simply assert that here, since 48 bits are good enough for 256 TB.
+ //
+ if (mPhysMemAddressWidth <= 36) {
+ mPhysMemAddressWidth = 36;
+ }
+ ASSERT (mPhysMemAddressWidth <= 48);
+}
+
+
+/**
+ Calculate the cap for the permanent PEI memory.
+**/
+STATIC
+UINT32
+GetPeiMemoryCap (
+ VOID
+ )
+{
+ BOOLEAN Page1GSupport;
+ UINT32 RegEax;
+ UINT32 RegEdx;
+ UINT32 Pml4Entries;
+ UINT32 PdpEntries;
+ UINTN TotalPages;
+
+ //
+ // If DXE is 32-bit, then just return the traditional 64 MB cap.
+ //
+#ifdef MDE_CPU_IA32
+ if (!FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
+ return SIZE_64MB;
+ }
+#endif
+
+ //
+ // Dependent on physical address width, PEI memory allocations can be
+ // dominated by the page tables built for 64-bit DXE. So we key the cap off
+ // of those. The code below is based on CreateIdentityMappingPageTables() in
+ // "MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c".
+ //
+ Page1GSupport = FALSE;
+ if (PcdGetBool (PcdUse1GPageTable)) {
+ AsmCpuid (0x80000000, &RegEax, NULL, NULL, NULL);
+ if (RegEax >= 0x80000001) {
+ AsmCpuid (0x80000001, NULL, NULL, NULL, &RegEdx);
+ if ((RegEdx & BIT26) != 0) {
+ Page1GSupport = TRUE;
+ }
+ }
+ }
+
+ if (mPhysMemAddressWidth <= 39) {
+ Pml4Entries = 1;
+ PdpEntries = 1 << (mPhysMemAddressWidth - 30);
+ ASSERT (PdpEntries <= 0x200);
+ } else {
+ Pml4Entries = 1 << (mPhysMemAddressWidth - 39);
+ ASSERT (Pml4Entries <= 0x200);
+ PdpEntries = 512;
+ }
+
+ TotalPages = Page1GSupport ? Pml4Entries + 1 :
+ (PdpEntries + 1) * Pml4Entries + 1;
+ ASSERT (TotalPages <= 0x40201);
+
+ //
+ // Add 64 MB for miscellaneous allocations. Note that for
+ // mPhysMemAddressWidth values close to 36, the cap will actually be
+ // dominated by this increment.
+ //
+ return (UINT32)(EFI_PAGES_TO_SIZE (TotalPages) + SIZE_64MB);
+}
+
+
+/**
+ Publish PEI core memory
+
+ @return EFI_SUCCESS The PEIM initialized successfully.
+
+**/
+EFI_STATUS
+PublishPeiMemory (
+ VOID
+ )
+{
+ EFI_STATUS Status;
+ EFI_PHYSICAL_ADDRESS MemoryBase;
+ UINT64 MemorySize;
+ UINT32 LowerMemorySize;
+ UINT32 PeiMemoryCap;
+
+ LowerMemorySize = GetSystemMemorySizeBelow4gb ();
+
+ if (mBootMode == BOOT_ON_S3_RESUME) {
+ MemoryBase = mS3AcpiReservedMemoryBase;
+ MemorySize = mS3AcpiReservedMemorySize;
+ } else {
+ PeiMemoryCap = GetPeiMemoryCap ();
+ DEBUG ((EFI_D_INFO, "%a: mPhysMemAddressWidth=%d PeiMemoryCap=%u KB\n",
+ __FUNCTION__, mPhysMemAddressWidth, PeiMemoryCap >> 10));
+
+ //
+ // Determine the range of memory to use during PEI
+ //
+ MemoryBase =
+ PcdGet32 (PcdOvmfDxeMemFvBase) + PcdGet32 (PcdOvmfDxeMemFvSize);
+ MemorySize = LowerMemorySize - MemoryBase;
+ if (MemorySize > PeiMemoryCap) {
+ MemoryBase = LowerMemorySize - PeiMemoryCap;
+ MemorySize = PeiMemoryCap;
+ }
+ }
+
+ //
+ // Publish this memory to the PEI Core
+ //
+ Status = PublishSystemMemory(MemoryBase, MemorySize);
+ ASSERT_EFI_ERROR (Status);
+
+ return Status;
+}
+
+
+/**
+ Publish system RAM and reserve memory regions
+
+**/
+VOID
+InitializeRamRegions (
+ VOID
+ )
+{
+ XenPublishRamRegions ();
+
+ if (mBootMode != BOOT_ON_S3_RESUME) {
+ //
+ // Reserve the lock box storage area
+ //
+ // Since this memory range will be used on S3 resume, it must be
+ // reserved as ACPI NVS.
+ //
+ // If S3 is unsupported, then various drivers might still write to the
+ // LockBox area. We ought to prevent DXE from serving allocation requests
+ // such that they would overlap the LockBox storage.
+ //
+ ZeroMem (
+ (VOID*)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
+ (UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize)
+ );
+ BuildMemoryAllocationHob (
+ (EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
+ (UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize),
+ EfiBootServicesData
+ );
+ }
+}
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
similarity index 56%
copy from OvmfPkg/PlatformPei/Platform.c
copy to OvmfPkg/XenPlatformPei/Platform.c
index 22139a64cb..2d567a4760 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -3,6 +3,7 @@
Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
+ Copyright (c) 2019, Citrix Systems, Inc.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
@@ -31,8 +32,6 @@
#include <Library/PciLib.h>
#include <Library/PeimEntryPoint.h>
#include <Library/PeiServicesLib.h>
-#include <Library/QemuFwCfgLib.h>
-#include <Library/QemuFwCfgS3Lib.h>
#include <Library/ResourcePublicationLib.h>
#include <Guid/MemoryTypeInformation.h>
#include <Ppi/MasterBootMode.h>
@@ -67,9 +66,6 @@ UINT16 mHostBridgeDevId;
EFI_BOOT_MODE mBootMode = BOOT_WITH_FULL_CONFIGURATION;
-BOOLEAN mS3Supported = FALSE;
-
-UINT32 mMaxCpuCount;
VOID
AddIoMemoryBaseSizeHob (
@@ -179,89 +175,6 @@ MemMapInitialization (
//
AddIoMemoryRangeHob (0x0A0000, BASE_1MB);
- if (!mXen) {
- UINT32 TopOfLowRam;
- UINT64 PciExBarBase;
- UINT32 PciBase;
- UINT32 PciSize;
-
- TopOfLowRam = GetSystemMemorySizeBelow4gb ();
- PciExBarBase = 0;
- if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
- //
- // The MMCONFIG area is expected to fall between the top of low RAM and
- // the base of the 32-bit PCI host aperture.
- //
- PciExBarBase = FixedPcdGet64 (PcdPciExpressBaseAddress);
- ASSERT (TopOfLowRam <= PciExBarBase);
- ASSERT (PciExBarBase <= MAX_UINT32 - SIZE_256MB);
- PciBase = (UINT32)(PciExBarBase + SIZE_256MB);
- } else {
- PciBase = (TopOfLowRam < BASE_2GB) ? BASE_2GB : TopOfLowRam;
- }
-
- //
- // address purpose size
- // ------------ -------- -------------------------
- // max(top, 2g) PCI MMIO 0xFC000000 - max(top, 2g)
- // 0xFC000000 gap 44 MB
- // 0xFEC00000 IO-APIC 4 KB
- // 0xFEC01000 gap 1020 KB
- // 0xFED00000 HPET 1 KB
- // 0xFED00400 gap 111 KB
- // 0xFED1C000 gap (PIIX4) / RCRB (ICH9) 16 KB
- // 0xFED20000 gap 896 KB
- // 0xFEE00000 LAPIC 1 MB
- //
- PciSize = 0xFC000000 - PciBase;
- AddIoMemoryBaseSizeHob (PciBase, PciSize);
- PcdStatus = PcdSet64S (PcdPciMmio32Base, PciBase);
- ASSERT_RETURN_ERROR (PcdStatus);
- PcdStatus = PcdSet64S (PcdPciMmio32Size, PciSize);
- ASSERT_RETURN_ERROR (PcdStatus);
-
- AddIoMemoryBaseSizeHob (0xFEC00000, SIZE_4KB);
- AddIoMemoryBaseSizeHob (0xFED00000, SIZE_1KB);
- if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
- AddIoMemoryBaseSizeHob (ICH9_ROOT_COMPLEX_BASE, SIZE_16KB);
- //
- // Note: there should be an
- //
- // AddIoMemoryBaseSizeHob (PciExBarBase, SIZE_256MB);
- //
- // call below, just like the one above for RCBA. However, Linux insists
- // that the MMCONFIG area be marked in the E820 or UEFI memory map as
- // "reserved memory" -- Linux does not content itself with a simple gap
- // in the memory map wherever the MCFG ACPI table points to.
- //
- // This appears to be a safety measure. The PCI Firmware Specification
- // (rev 3.1) says in 4.1.2. "MCFG Table Description": "The resources can
- // *optionally* be returned in [...] EFIGetMemoryMap as reserved memory
- // [...]". (Emphasis added here.)
- //
- // Normally we add memory resource descriptor HOBs in
- // QemuInitializeRam(), and pre-allocate from those with memory
- // allocation HOBs in InitializeRamRegions(). However, the MMCONFIG area
- // is most definitely not RAM; so, as an exception, cover it with
- // uncacheable reserved memory right here.
- //
- AddReservedMemoryBaseSizeHob (PciExBarBase, SIZE_256MB, FALSE);
- BuildMemoryAllocationHob (PciExBarBase, SIZE_256MB,
- EfiReservedMemoryType);
- }
- AddIoMemoryBaseSizeHob (PcdGet32(PcdCpuLocalApicBaseAddress), SIZE_1MB);
-
- //
- // On Q35, the IO Port space is available for PCI resource allocations from
- // 0x6000 up.
- //
- if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
- PciIoBase = 0x6000;
- PciIoSize = 0xA000;
- ASSERT ((ICH9_PMBASE_VALUE & 0xF000) < PciIoBase);
- }
- }
-
//
// Add PCI IO Port space available for PCI resource allocations.
//
@@ -278,71 +191,6 @@ MemMapInitialization (
ASSERT_RETURN_ERROR (PcdStatus);
}
-EFI_STATUS
-GetNamedFwCfgBoolean (
- IN CHAR8 *FwCfgFileName,
- OUT BOOLEAN *Setting
- )
-{
- EFI_STATUS Status;
- FIRMWARE_CONFIG_ITEM FwCfgItem;
- UINTN FwCfgSize;
- UINT8 Value[3];
-
- Status = QemuFwCfgFindFile (FwCfgFileName, &FwCfgItem, &FwCfgSize);
- if (EFI_ERROR (Status)) {
- return Status;
- }
- if (FwCfgSize > sizeof Value) {
- return EFI_BAD_BUFFER_SIZE;
- }
- QemuFwCfgSelectItem (FwCfgItem);
- QemuFwCfgReadBytes (FwCfgSize, Value);
-
- if ((FwCfgSize == 1) ||
- (FwCfgSize == 2 && Value[1] == '\n') ||
- (FwCfgSize == 3 && Value[1] == '\r' && Value[2] == '\n')) {
- switch (Value[0]) {
- case '0':
- case 'n':
- case 'N':
- *Setting = FALSE;
- return EFI_SUCCESS;
-
- case '1':
- case 'y':
- case 'Y':
- *Setting = TRUE;
- return EFI_SUCCESS;
-
- default:
- break;
- }
- }
- return EFI_PROTOCOL_ERROR;
-}
-
-#define UPDATE_BOOLEAN_PCD_FROM_FW_CFG(TokenName) \
- do { \
- BOOLEAN Setting; \
- RETURN_STATUS PcdStatus; \
- \
- if (!EFI_ERROR (GetNamedFwCfgBoolean ( \
- "opt/ovmf/" #TokenName, &Setting))) { \
- PcdStatus = PcdSetBoolS (TokenName, Setting); \
- ASSERT_RETURN_ERROR (PcdStatus); \
- } \
- } while (0)
-
-VOID
-NoexecDxeInitialization (
- VOID
- )
-{
- UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdPropertiesTableEnable);
- UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdSetNxForStack);
-}
-
VOID
PciExBarInitialization (
VOID
@@ -547,67 +395,6 @@ DebugDumpCmos (
}
-VOID
-S3Verification (
- VOID
- )
-{
-#if defined (MDE_CPU_X64)
- if (FeaturePcdGet (PcdSmmSmramRequire) && mS3Supported) {
- DEBUG ((EFI_D_ERROR,
- "%a: S3Resume2Pei doesn't support X64 PEI + SMM yet.\n", __FUNCTION__));
- DEBUG ((EFI_D_ERROR,
- "%a: Please disable S3 on the QEMU command line (see the README),\n",
- __FUNCTION__));
- DEBUG ((EFI_D_ERROR,
- "%a: or build OVMF with \"OvmfPkgIa32X64.dsc\".\n", __FUNCTION__));
- ASSERT (FALSE);
- CpuDeadLoop ();
- }
-#endif
-}
-
-
-/**
- Fetch the number of boot CPUs from QEMU and expose it to UefiCpuPkg modules.
- Set the mMaxCpuCount variable.
-**/
-VOID
-MaxCpuCountInitialization (
- VOID
- )
-{
- UINT16 ProcessorCount;
- RETURN_STATUS PcdStatus;
-
- QemuFwCfgSelectItem (QemuFwCfgItemSmpCpuCount);
- ProcessorCount = QemuFwCfgRead16 ();
- //
- // If the fw_cfg key or fw_cfg entirely is unavailable, load mMaxCpuCount
- // from the PCD default. No change to PCDs.
- //
- if (ProcessorCount == 0) {
- mMaxCpuCount = PcdGet32 (PcdCpuMaxLogicalProcessorNumber);
- return;
- }
- //
- // Otherwise, set mMaxCpuCount to the value reported by QEMU.
- //
- mMaxCpuCount = ProcessorCount;
- //
- // Additionally, tell UefiCpuPkg modules (a) the exact number of VCPUs, (b)
- // to wait, in the initial AP bringup, exactly as long as it takes for all of
- // the APs to report in. For this, we set the longest representable timeout
- // (approx. 71 minutes).
- //
- PcdStatus = PcdSet32S (PcdCpuMaxLogicalProcessorNumber, ProcessorCount);
- ASSERT_RETURN_ERROR (PcdStatus);
- PcdStatus = PcdSet32S (PcdCpuApInitTimeOutInMicroSeconds, MAX_UINT32);
- ASSERT_RETURN_ERROR (PcdStatus);
- DEBUG ((DEBUG_INFO, "%a: QEMU reports %d processor(s)\n", __FUNCTION__,
- ProcessorCount));
-}
-
/**
Perform Platform PEI initialization.
@@ -620,62 +407,43 @@ MaxCpuCountInitialization (
**/
EFI_STATUS
EFIAPI
-InitializePlatform (
+InitializeXenPlatform (
IN EFI_PEI_FILE_HANDLE FileHandle,
IN CONST EFI_PEI_SERVICES **PeiServices
)
{
- EFI_STATUS Status;
-
DEBUG ((DEBUG_INFO, "Platform PEIM Loaded\n"));
DebugDumpCmos ();
- XenDetect ();
-
- if (QemuFwCfgS3Enabled ()) {
- DEBUG ((EFI_D_INFO, "S3 support was detected on QEMU\n"));
- mS3Supported = TRUE;
- Status = PcdSetBoolS (PcdAcpiS3Enable, TRUE);
- ASSERT_EFI_ERROR (Status);
+ if (!XenDetect ()) {
+ DEBUG ((EFI_D_ERROR, "ERROR: Xen isn't detected\n"));
+ CpuDeadLoop ();
}
- S3Verification ();
BootModeInitialization ();
AddressWidthInitialization ();
- MaxCpuCountInitialization ();
//
// Query Host Bridge DID
//
mHostBridgeDevId = PciRead16 (OVMF_HOSTBRIDGE_DID);
- if (FeaturePcdGet (PcdSmmSmramRequire)) {
- Q35TsegMbytesInitialization ();
- }
-
PublishPeiMemory ();
InitializeRamRegions ();
- if (mXen) {
- DEBUG ((EFI_D_INFO, "Xen was detected\n"));
- InitializeXen ();
- }
+ InitializeXen ();
if (mBootMode != BOOT_ON_S3_RESUME) {
- if (!FeaturePcdGet (PcdSmmSmramRequire)) {
- ReserveEmuVariableNvStore ();
- }
+ ReserveEmuVariableNvStore ();
PeiFvInitialization ();
MemMapInitialization ();
- NoexecDxeInitialization ();
}
InstallClearCacheCallback ();
AmdSevInitialize ();
MiscInitialization ();
- InstallFeatureControlCallback ();
return EFI_SUCCESS;
}
diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
similarity index 94%
copy from OvmfPkg/PlatformPei/Xen.c
copy to OvmfPkg/XenPlatformPei/Xen.c
index ab38f97a67..7c82e5b69b 100644
--- a/OvmfPkg/PlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -3,6 +3,7 @@
Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
+ Copyright (c) 2019, Citrix Systems, Inc.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
@@ -34,8 +35,6 @@
#include "Platform.h"
#include "Xen.h"
-BOOLEAN mXen = FALSE;
-
STATIC UINT32 mXenLeaf = 0;
EFI_XEN_INFO mXenInfo;
@@ -143,7 +142,6 @@ XenDetect (
(UINT32 *) &Signature[8]);
if (!AsciiStrCmp ((CHAR8 *) Signature, "XenVMMXenVMM")) {
- mXen = TRUE;
return TRUE;
}
}
@@ -162,10 +160,6 @@ XenPublishRamRegions (
UINT32 E820EntriesCount;
EFI_STATUS Status;
- if (!mXen) {
- return;
- }
-
DEBUG ((EFI_D_INFO, "Using memory map provided by Xen\n"));
//
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 04/31] OvmfPkg: Introduce XenPlatformPei
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
A copy of OvmfPkg/PlatformPei without some of QEMU specific
initialization, Xen does not support QemuFwCfg.
This new module will be adjusted to accommodate Xen PVH.
fw_cfg dependents that have been removed, which are dynamically skipped
when running PlatformPei on Xen:
- GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
(experimental) "opt/ovmf/X-PciMmio64Mb" file
- GetFirstNonAddress(): honoring the hotplug DIMM area
("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO
aperture
- NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
PcdSetNxForStack are left constant FALSE (not set dynamically from
fw_cfg "opt/ovmf/PcdXxxx")
- MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
PcdCpuMaxLogicalProcessorNumber is used intact and
PcdCpuApInitTimeOutInMicroSeconds is never changed or used.
- InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
consulting "etc/system-states" via QemuFwCfgS3Enabled()).
- InstallFeatureControlCallback(): the feature control MSR is not set
from "etc/msr_feature_control"
(also removed FeatureControl.c as there is nothing been executed)
Also removed:
- SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
assumed FALSE) in PublishPeiMemory(),
- QemuInitializeRam() entirely,
Xen related changes:
- Have removed the module variable mXen, as it should be always true.
- Have the platform PEI initialization fails if Xen has not been
detected.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenOvmf.dsc | 2 +-
OvmfPkg/XenOvmf.fdf | 2 +-
OvmfPkg/{PlatformPei/PlatformPei.inf => XenPlatformPei/XenPlatformPei.inf} | 28 +-
OvmfPkg/{PlatformPei => XenPlatformPei}/Cmos.h | 2 +
OvmfPkg/{PlatformPei => XenPlatformPei}/Platform.h | 13 +-
OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.h | 0
OvmfPkg/{PlatformPei => XenPlatformPei}/AmdSev.c | 30 +-
OvmfPkg/{PlatformPei => XenPlatformPei}/ClearCache.c | 1 +
OvmfPkg/{PlatformPei => XenPlatformPei}/Cmos.c | 2 +
OvmfPkg/{PlatformPei => XenPlatformPei}/Fv.c | 26 +-
OvmfPkg/XenPlatformPei/MemDetect.c | 427 ++++++++++++++++++++
OvmfPkg/{PlatformPei => XenPlatformPei}/Platform.c | 246 +----------
OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.c | 8 +-
13 files changed, 453 insertions(+), 334 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 6161133fa8..7b8a1fdf6b 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -531,7 +531,7 @@ [Components]
}
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
- OvmfPkg/PlatformPei/PlatformPei.inf
+ OvmfPkg/XenPlatformPei/XenPlatformPei.inf
UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
UefiCpuPkg/CpuMpPei/CpuMpPei.inf
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 292cf4b492..295e30ca3f 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -158,7 +158,7 @@ [FV.PEIFV]
INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
-INF OvmfPkg/PlatformPei/PlatformPei.inf
+INF OvmfPkg/XenPlatformPei/XenPlatformPei.inf
INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
similarity index 69%
copy from OvmfPkg/PlatformPei/PlatformPei.inf
copy to OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 5c8dd0fe6d..c8d25c115f 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -3,6 +3,7 @@
#
# This module provides platform specific function to detect boot mode.
# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -16,11 +17,11 @@
[Defines]
INF_VERSION = 0x00010005
- BASE_NAME = PlatformPei
- FILE_GUID = 222c386d-5abc-4fb4-b124-fbb82488acf4
+ BASE_NAME = XenPlatformPei
+ FILE_GUID = f112a6ee-993a-4f0b-8295-e52029d9b4ba
MODULE_TYPE = PEIM
VERSION_STRING = 1.0
- ENTRY_POINT = InitializePlatform
+ ENTRY_POINT = InitializeXenPlatform
#
# The following information is for reference only and not required by the build tools.
@@ -33,7 +34,6 @@ [Sources]
ClearCache.c
Cmos.c
Cmos.h
- FeatureControl.c
Fv.c
MemDetect.c
Platform.c
@@ -62,10 +62,7 @@ [LibraryClasses]
PciLib
ResourcePublicationLib
PeiServicesLib
- PeiServicesTablePointerLib
PeimEntryPoint
- QemuFwCfgLib
- QemuFwCfgS3Lib
MtrrLib
MemEncryptSevLib
PcdLib
@@ -75,13 +72,8 @@ [Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
- gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
- gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
- gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
- gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
- gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize
@@ -89,31 +81,19 @@ [Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size
- gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
- gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
- gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
- gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
- gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
- gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
- gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
- gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds
- gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
[FixedPcd]
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
-[FeaturePcd]
- gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
-
[Ppis]
gEfiPeiMasterBootModePpiGuid
gEfiPeiMpServicesPpiGuid
diff --git a/OvmfPkg/PlatformPei/Cmos.h b/OvmfPkg/XenPlatformPei/Cmos.h
similarity index 92%
copy from OvmfPkg/PlatformPei/Cmos.h
copy to OvmfPkg/XenPlatformPei/Cmos.h
index 949f884c2c..defe677122 100644
--- a/OvmfPkg/PlatformPei/Cmos.h
+++ b/OvmfPkg/XenPlatformPei/Cmos.h
@@ -2,6 +2,8 @@
PC/AT CMOS access routines
Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
diff --git a/OvmfPkg/PlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
similarity index 88%
copy from OvmfPkg/PlatformPei/Platform.h
copy to OvmfPkg/XenPlatformPei/Platform.h
index b12a5c1f5f..6ccd5eb66c 100644
--- a/OvmfPkg/PlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -2,6 +2,8 @@
Platform PEI module include file.
Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -78,11 +80,6 @@ PeiFvInitialization (
VOID
);
-VOID
-InstallFeatureControlCallback (
- VOID
- );
-
VOID
InstallClearCacheCallback (
VOID
@@ -103,8 +100,6 @@ AmdSevInitialize (
VOID
);
-extern BOOLEAN mXen;
-
VOID
XenPublishRamRegions (
VOID
@@ -112,12 +107,8 @@ XenPublishRamRegions (
extern EFI_BOOT_MODE mBootMode;
-extern BOOLEAN mS3Supported;
-
extern UINT8 mPhysMemAddressWidth;
-extern UINT32 mMaxCpuCount;
-
extern UINT16 mHostBridgeDevId;
#endif // _PLATFORM_PEI_H_INCLUDED_
diff --git a/OvmfPkg/PlatformPei/Xen.h b/OvmfPkg/XenPlatformPei/Xen.h
similarity index 100%
copy from OvmfPkg/PlatformPei/Xen.h
copy to OvmfPkg/XenPlatformPei/Xen.h
diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/XenPlatformPei/AmdSev.c
similarity index 61%
copy from OvmfPkg/PlatformPei/AmdSev.c
copy to OvmfPkg/XenPlatformPei/AmdSev.c
index 2e14eaf8c3..1a1f46291f 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/XenPlatformPei/AmdSev.c
@@ -2,6 +2,7 @@
Initialize Secure Encrypted Virtualization (SEV) support
Copyright (c) 2017, Advanced Micro Devices. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
@@ -16,7 +17,6 @@
// The package level header files this module uses
//
#include <Library/DebugLib.h>
-#include <Library/HobLib.h>
#include <Library/MemEncryptSevLib.h>
#include <Library/PcdLib.h>
#include <PiPei.h>
@@ -67,32 +67,4 @@ AmdSevInitialize (
//
PcdStatus = PcdSet32S (PcdOptionRomImageVerificationPolicy, 0x4);
ASSERT_RETURN_ERROR (PcdStatus);
-
- //
- // When SMM is required, cover the pages containing the initial SMRAM Save
- // State Map with a memory allocation HOB:
- //
- // There's going to be a time interval between our decrypting those pages for
- // SMBASE relocation and re-encrypting the same pages after SMBASE
- // relocation. We shall ensure that the DXE phase stay away from those pages
- // until after re-encryption, in order to prevent an information leak to the
- // hypervisor.
- //
- if (FeaturePcdGet (PcdSmmSmramRequire) && (mBootMode != BOOT_ON_S3_RESUME)) {
- RETURN_STATUS LocateMapStatus;
- UINTN MapPagesBase;
- UINTN MapPagesCount;
-
- LocateMapStatus = MemEncryptSevLocateInitialSmramSaveStateMapPages (
- &MapPagesBase,
- &MapPagesCount
- );
- ASSERT_RETURN_ERROR (LocateMapStatus);
-
- BuildMemoryAllocationHob (
- MapPagesBase, // BaseAddress
- EFI_PAGES_TO_SIZE (MapPagesCount), // Length
- EfiBootServicesData // MemoryType
- );
- }
}
diff --git a/OvmfPkg/PlatformPei/ClearCache.c b/OvmfPkg/XenPlatformPei/ClearCache.c
similarity index 95%
copy from OvmfPkg/PlatformPei/ClearCache.c
copy to OvmfPkg/XenPlatformPei/ClearCache.c
index 7d15fd925c..78e22124e3 100644
--- a/OvmfPkg/PlatformPei/ClearCache.c
+++ b/OvmfPkg/XenPlatformPei/ClearCache.c
@@ -6,6 +6,7 @@
sake.
Copyright (C) 2018, Red Hat, Inc.
+ Copyright (c) 2019, Citrix Systems, Inc.
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
diff --git a/OvmfPkg/PlatformPei/Cmos.c b/OvmfPkg/XenPlatformPei/Cmos.c
similarity index 92%
copy from OvmfPkg/PlatformPei/Cmos.c
copy to OvmfPkg/XenPlatformPei/Cmos.c
index 48ed2cb8f4..174ec773ec 100644
--- a/OvmfPkg/PlatformPei/Cmos.c
+++ b/OvmfPkg/XenPlatformPei/Cmos.c
@@ -2,6 +2,8 @@
PC/AT CMOS access routines
Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
diff --git a/OvmfPkg/PlatformPei/Fv.c b/OvmfPkg/XenPlatformPei/Fv.c
similarity index 72%
copy from OvmfPkg/PlatformPei/Fv.c
copy to OvmfPkg/XenPlatformPei/Fv.c
index 248c585085..388e8768bf 100644
--- a/OvmfPkg/PlatformPei/Fv.c
+++ b/OvmfPkg/XenPlatformPei/Fv.c
@@ -2,6 +2,8 @@
Build FV related hobs for platform.
Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -32,8 +34,6 @@ PeiFvInitialization (
VOID
)
{
- BOOLEAN SecureS3Needed;
-
DEBUG ((EFI_D_INFO, "Platform PEI Firmware Volume Initialization\n"));
//
@@ -44,7 +44,7 @@ PeiFvInitialization (
BuildMemoryAllocationHob (
PcdGet32 (PcdOvmfPeiMemFvBase),
PcdGet32 (PcdOvmfPeiMemFvSize),
- mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
+ EfiBootServicesData
);
//
@@ -52,8 +52,6 @@ PeiFvInitialization (
//
BuildFvHob (PcdGet32 (PcdOvmfDxeMemFvBase), PcdGet32 (PcdOvmfDxeMemFvSize));
- SecureS3Needed = mS3Supported && FeaturePcdGet (PcdSmmSmramRequire);
-
//
// Create a memory allocation HOB for the DXE FV.
//
@@ -65,25 +63,9 @@ PeiFvInitialization (
BuildMemoryAllocationHob (
PcdGet32 (PcdOvmfDxeMemFvBase),
PcdGet32 (PcdOvmfDxeMemFvSize),
- SecureS3Needed ? EfiACPIMemoryNVS : EfiBootServicesData
+ EfiBootServicesData
);
- //
- // Additionally, said decompression will use temporary memory above the end
- // of DXEFV, so let's keep away the OS from there too.
- //
- if (SecureS3Needed) {
- UINT32 DxeMemFvEnd;
-
- DxeMemFvEnd = PcdGet32 (PcdOvmfDxeMemFvBase) +
- PcdGet32 (PcdOvmfDxeMemFvSize);
- BuildMemoryAllocationHob (
- DxeMemFvEnd,
- PcdGet32 (PcdOvmfDecompressionScratchEnd) - DxeMemFvEnd,
- EfiACPIMemoryNVS
- );
- }
-
//
// Let PEI know about the DXE FV so it can find the DXE Core
//
diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c b/OvmfPkg/XenPlatformPei/MemDetect.c
new file mode 100644
index 0000000000..db3d387d1c
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/MemDetect.c
@@ -0,0 +1,427 @@
+/**@file
+ Memory Detection for Virtual Machines.
+
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD License
+ which accompanies this distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+Module Name:
+
+ MemDetect.c
+
+**/
+
+//
+// The package level header files this module uses
+//
+#include <IndustryStandard/Q35MchIch9.h>
+#include <PiPei.h>
+
+//
+// The Library classes this module consumes
+//
+#include <Library/BaseLib.h>
+#include <Library/BaseMemoryLib.h>
+#include <Library/DebugLib.h>
+#include <Library/HobLib.h>
+#include <Library/IoLib.h>
+#include <Library/PcdLib.h>
+#include <Library/PciLib.h>
+#include <Library/PeimEntryPoint.h>
+#include <Library/ResourcePublicationLib.h>
+
+#include "Platform.h"
+#include "Cmos.h"
+
+UINT8 mPhysMemAddressWidth;
+
+STATIC UINT32 mS3AcpiReservedMemoryBase;
+STATIC UINT32 mS3AcpiReservedMemorySize;
+
+STATIC UINT16 mQ35TsegMbytes;
+
+VOID
+Q35TsegMbytesInitialization (
+ VOID
+ )
+{
+ UINT16 ExtendedTsegMbytes;
+ RETURN_STATUS PcdStatus;
+
+ if (mHostBridgeDevId != INTEL_Q35_MCH_DEVICE_ID) {
+ DEBUG ((
+ DEBUG_ERROR,
+ "%a: no TSEG (SMRAM) on host bridge DID=0x%04x; "
+ "only DID=0x%04x (Q35) is supported\n",
+ __FUNCTION__,
+ mHostBridgeDevId,
+ INTEL_Q35_MCH_DEVICE_ID
+ ));
+ ASSERT (FALSE);
+ CpuDeadLoop ();
+ }
+
+ //
+ // Check if QEMU offers an extended TSEG.
+ //
+ // This can be seen from writing MCH_EXT_TSEG_MB_QUERY to the MCH_EXT_TSEG_MB
+ // register, and reading back the register.
+ //
+ // On a QEMU machine type that does not offer an extended TSEG, the initial
+ // write overwrites whatever value a malicious guest OS may have placed in
+ // the (unimplemented) register, before entering S3 or rebooting.
+ // Subsequently, the read returns MCH_EXT_TSEG_MB_QUERY unchanged.
+ //
+ // On a QEMU machine type that offers an extended TSEG, the initial write
+ // triggers an update to the register. Subsequently, the value read back
+ // (which is guaranteed to differ from MCH_EXT_TSEG_MB_QUERY) tells us the
+ // number of megabytes.
+ //
+ PciWrite16 (DRAMC_REGISTER_Q35 (MCH_EXT_TSEG_MB), MCH_EXT_TSEG_MB_QUERY);
+ ExtendedTsegMbytes = PciRead16 (DRAMC_REGISTER_Q35 (MCH_EXT_TSEG_MB));
+ if (ExtendedTsegMbytes == MCH_EXT_TSEG_MB_QUERY) {
+ mQ35TsegMbytes = PcdGet16 (PcdQ35TsegMbytes);
+ return;
+ }
+
+ DEBUG ((
+ DEBUG_INFO,
+ "%a: QEMU offers an extended TSEG (%d MB)\n",
+ __FUNCTION__,
+ ExtendedTsegMbytes
+ ));
+ PcdStatus = PcdSet16S (PcdQ35TsegMbytes, ExtendedTsegMbytes);
+ ASSERT_RETURN_ERROR (PcdStatus);
+ mQ35TsegMbytes = ExtendedTsegMbytes;
+}
+
+
+UINT32
+GetSystemMemorySizeBelow4gb (
+ VOID
+ )
+{
+ UINT8 Cmos0x34;
+ UINT8 Cmos0x35;
+
+ //
+ // CMOS 0x34/0x35 specifies the system memory above 16 MB.
+ // * CMOS(0x35) is the high byte
+ // * CMOS(0x34) is the low byte
+ // * The size is specified in 64kb chunks
+ // * Since this is memory above 16MB, the 16MB must be added
+ // into the calculation to get the total memory size.
+ //
+
+ Cmos0x34 = (UINT8) CmosRead8 (0x34);
+ Cmos0x35 = (UINT8) CmosRead8 (0x35);
+
+ return (UINT32) (((UINTN)((Cmos0x35 << 8) + Cmos0x34) << 16) + SIZE_16MB);
+}
+
+
+STATIC
+UINT64
+GetSystemMemorySizeAbove4gb (
+ )
+{
+ UINT32 Size;
+ UINTN CmosIndex;
+
+ //
+ // CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
+ // * CMOS(0x5d) is the most significant size byte
+ // * CMOS(0x5c) is the middle size byte
+ // * CMOS(0x5b) is the least significant size byte
+ // * The size is specified in 64kb chunks
+ //
+
+ Size = 0;
+ for (CmosIndex = 0x5d; CmosIndex >= 0x5b; CmosIndex--) {
+ Size = (UINT32) (Size << 8) + (UINT32) CmosRead8 (CmosIndex);
+ }
+
+ return LShiftU64 (Size, 16);
+}
+
+
+/**
+ Return the highest address that DXE could possibly use, plus one.
+**/
+STATIC
+UINT64
+GetFirstNonAddress (
+ VOID
+ )
+{
+ UINT64 FirstNonAddress;
+ UINT64 Pci64Base, Pci64Size;
+ RETURN_STATUS PcdStatus;
+
+ FirstNonAddress = BASE_4GB + GetSystemMemorySizeAbove4gb ();
+
+ //
+ // If DXE is 32-bit, then we're done; PciBusDxe will degrade 64-bit MMIO
+ // resources to 32-bit anyway. See DegradeResource() in
+ // "PciResourceSupport.c".
+ //
+#ifdef MDE_CPU_IA32
+ if (!FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
+ return FirstNonAddress;
+ }
+#endif
+
+ //
+ // 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);
+
+ if (Pci64Size == 0) {
+ if (mBootMode != BOOT_ON_S3_RESUME) {
+ DEBUG ((EFI_D_INFO, "%a: disabling 64-bit PCI host aperture\n",
+ __FUNCTION__));
+ PcdStatus = PcdSet64S (PcdPciMmio64Size, 0);
+ ASSERT_RETURN_ERROR (PcdStatus);
+ }
+
+ //
+ // There's nothing more to do; the amount of memory above 4GB fully
+ // determines the highest address plus one. The memory hotplug area (see
+ // below) plays no role for the firmware in this case.
+ //
+ return FirstNonAddress;
+ }
+
+ //
+ // SeaBIOS aligns both boundaries of the 64-bit PCI host aperture to 1GB, so
+ // that the host can map it with 1GB hugepages. Follow suit.
+ //
+ Pci64Base = ALIGN_VALUE (FirstNonAddress, (UINT64)SIZE_1GB);
+ Pci64Size = ALIGN_VALUE (Pci64Size, (UINT64)SIZE_1GB);
+
+ //
+ // The 64-bit PCI host aperture should also be "naturally" aligned. The
+ // alignment is determined by rounding the size of the aperture down to the
+ // next smaller or equal power of two. That is, align the aperture by the
+ // largest BAR size that can fit into it.
+ //
+ Pci64Base = ALIGN_VALUE (Pci64Base, GetPowerOfTwo64 (Pci64Size));
+
+ if (mBootMode != BOOT_ON_S3_RESUME) {
+ //
+ // The core PciHostBridgeDxe driver will automatically add this range to
+ // the GCD memory space map through our PciHostBridgeLib instance; here we
+ // only need to set the PCDs.
+ //
+ PcdStatus = PcdSet64S (PcdPciMmio64Base, Pci64Base);
+ ASSERT_RETURN_ERROR (PcdStatus);
+ PcdStatus = PcdSet64S (PcdPciMmio64Size, Pci64Size);
+ ASSERT_RETURN_ERROR (PcdStatus);
+
+ DEBUG ((EFI_D_INFO, "%a: Pci64Base=0x%Lx Pci64Size=0x%Lx\n",
+ __FUNCTION__, Pci64Base, Pci64Size));
+ }
+
+ //
+ // The useful address space ends with the 64-bit PCI host aperture.
+ //
+ FirstNonAddress = Pci64Base + Pci64Size;
+ return FirstNonAddress;
+}
+
+
+/**
+ Initialize the mPhysMemAddressWidth variable, based on guest RAM size.
+**/
+VOID
+AddressWidthInitialization (
+ VOID
+ )
+{
+ UINT64 FirstNonAddress;
+
+ //
+ // As guest-physical memory size grows, the permanent PEI RAM requirements
+ // are dominated by the identity-mapping page tables built by the DXE IPL.
+ // The DXL IPL keys off of the physical address bits advertized in the CPU
+ // HOB. To conserve memory, we calculate the minimum address width here.
+ //
+ FirstNonAddress = GetFirstNonAddress ();
+ mPhysMemAddressWidth = (UINT8)HighBitSet64 (FirstNonAddress);
+
+ //
+ // If FirstNonAddress is not an integral power of two, then we need an
+ // additional bit.
+ //
+ if ((FirstNonAddress & (FirstNonAddress - 1)) != 0) {
+ ++mPhysMemAddressWidth;
+ }
+
+ //
+ // The minimum address width is 36 (covers up to and excluding 64 GB, which
+ // is the maximum for Ia32 + PAE). The theoretical architecture maximum for
+ // X64 long mode is 52 bits, but the DXE IPL clamps that down to 48 bits. We
+ // can simply assert that here, since 48 bits are good enough for 256 TB.
+ //
+ if (mPhysMemAddressWidth <= 36) {
+ mPhysMemAddressWidth = 36;
+ }
+ ASSERT (mPhysMemAddressWidth <= 48);
+}
+
+
+/**
+ Calculate the cap for the permanent PEI memory.
+**/
+STATIC
+UINT32
+GetPeiMemoryCap (
+ VOID
+ )
+{
+ BOOLEAN Page1GSupport;
+ UINT32 RegEax;
+ UINT32 RegEdx;
+ UINT32 Pml4Entries;
+ UINT32 PdpEntries;
+ UINTN TotalPages;
+
+ //
+ // If DXE is 32-bit, then just return the traditional 64 MB cap.
+ //
+#ifdef MDE_CPU_IA32
+ if (!FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
+ return SIZE_64MB;
+ }
+#endif
+
+ //
+ // Dependent on physical address width, PEI memory allocations can be
+ // dominated by the page tables built for 64-bit DXE. So we key the cap off
+ // of those. The code below is based on CreateIdentityMappingPageTables() in
+ // "MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c".
+ //
+ Page1GSupport = FALSE;
+ if (PcdGetBool (PcdUse1GPageTable)) {
+ AsmCpuid (0x80000000, &RegEax, NULL, NULL, NULL);
+ if (RegEax >= 0x80000001) {
+ AsmCpuid (0x80000001, NULL, NULL, NULL, &RegEdx);
+ if ((RegEdx & BIT26) != 0) {
+ Page1GSupport = TRUE;
+ }
+ }
+ }
+
+ if (mPhysMemAddressWidth <= 39) {
+ Pml4Entries = 1;
+ PdpEntries = 1 << (mPhysMemAddressWidth - 30);
+ ASSERT (PdpEntries <= 0x200);
+ } else {
+ Pml4Entries = 1 << (mPhysMemAddressWidth - 39);
+ ASSERT (Pml4Entries <= 0x200);
+ PdpEntries = 512;
+ }
+
+ TotalPages = Page1GSupport ? Pml4Entries + 1 :
+ (PdpEntries + 1) * Pml4Entries + 1;
+ ASSERT (TotalPages <= 0x40201);
+
+ //
+ // Add 64 MB for miscellaneous allocations. Note that for
+ // mPhysMemAddressWidth values close to 36, the cap will actually be
+ // dominated by this increment.
+ //
+ return (UINT32)(EFI_PAGES_TO_SIZE (TotalPages) + SIZE_64MB);
+}
+
+
+/**
+ Publish PEI core memory
+
+ @return EFI_SUCCESS The PEIM initialized successfully.
+
+**/
+EFI_STATUS
+PublishPeiMemory (
+ VOID
+ )
+{
+ EFI_STATUS Status;
+ EFI_PHYSICAL_ADDRESS MemoryBase;
+ UINT64 MemorySize;
+ UINT32 LowerMemorySize;
+ UINT32 PeiMemoryCap;
+
+ LowerMemorySize = GetSystemMemorySizeBelow4gb ();
+
+ if (mBootMode == BOOT_ON_S3_RESUME) {
+ MemoryBase = mS3AcpiReservedMemoryBase;
+ MemorySize = mS3AcpiReservedMemorySize;
+ } else {
+ PeiMemoryCap = GetPeiMemoryCap ();
+ DEBUG ((EFI_D_INFO, "%a: mPhysMemAddressWidth=%d PeiMemoryCap=%u KB\n",
+ __FUNCTION__, mPhysMemAddressWidth, PeiMemoryCap >> 10));
+
+ //
+ // Determine the range of memory to use during PEI
+ //
+ MemoryBase =
+ PcdGet32 (PcdOvmfDxeMemFvBase) + PcdGet32 (PcdOvmfDxeMemFvSize);
+ MemorySize = LowerMemorySize - MemoryBase;
+ if (MemorySize > PeiMemoryCap) {
+ MemoryBase = LowerMemorySize - PeiMemoryCap;
+ MemorySize = PeiMemoryCap;
+ }
+ }
+
+ //
+ // Publish this memory to the PEI Core
+ //
+ Status = PublishSystemMemory(MemoryBase, MemorySize);
+ ASSERT_EFI_ERROR (Status);
+
+ return Status;
+}
+
+
+/**
+ Publish system RAM and reserve memory regions
+
+**/
+VOID
+InitializeRamRegions (
+ VOID
+ )
+{
+ XenPublishRamRegions ();
+
+ if (mBootMode != BOOT_ON_S3_RESUME) {
+ //
+ // Reserve the lock box storage area
+ //
+ // Since this memory range will be used on S3 resume, it must be
+ // reserved as ACPI NVS.
+ //
+ // If S3 is unsupported, then various drivers might still write to the
+ // LockBox area. We ought to prevent DXE from serving allocation requests
+ // such that they would overlap the LockBox storage.
+ //
+ ZeroMem (
+ (VOID*)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
+ (UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize)
+ );
+ BuildMemoryAllocationHob (
+ (EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
+ (UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize),
+ EfiBootServicesData
+ );
+ }
+}
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
similarity index 56%
copy from OvmfPkg/PlatformPei/Platform.c
copy to OvmfPkg/XenPlatformPei/Platform.c
index 22139a64cb..2d567a4760 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -3,6 +3,7 @@
Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
+ Copyright (c) 2019, Citrix Systems, Inc.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
@@ -31,8 +32,6 @@
#include <Library/PciLib.h>
#include <Library/PeimEntryPoint.h>
#include <Library/PeiServicesLib.h>
-#include <Library/QemuFwCfgLib.h>
-#include <Library/QemuFwCfgS3Lib.h>
#include <Library/ResourcePublicationLib.h>
#include <Guid/MemoryTypeInformation.h>
#include <Ppi/MasterBootMode.h>
@@ -67,9 +66,6 @@ UINT16 mHostBridgeDevId;
EFI_BOOT_MODE mBootMode = BOOT_WITH_FULL_CONFIGURATION;
-BOOLEAN mS3Supported = FALSE;
-
-UINT32 mMaxCpuCount;
VOID
AddIoMemoryBaseSizeHob (
@@ -179,89 +175,6 @@ MemMapInitialization (
//
AddIoMemoryRangeHob (0x0A0000, BASE_1MB);
- if (!mXen) {
- UINT32 TopOfLowRam;
- UINT64 PciExBarBase;
- UINT32 PciBase;
- UINT32 PciSize;
-
- TopOfLowRam = GetSystemMemorySizeBelow4gb ();
- PciExBarBase = 0;
- if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
- //
- // The MMCONFIG area is expected to fall between the top of low RAM and
- // the base of the 32-bit PCI host aperture.
- //
- PciExBarBase = FixedPcdGet64 (PcdPciExpressBaseAddress);
- ASSERT (TopOfLowRam <= PciExBarBase);
- ASSERT (PciExBarBase <= MAX_UINT32 - SIZE_256MB);
- PciBase = (UINT32)(PciExBarBase + SIZE_256MB);
- } else {
- PciBase = (TopOfLowRam < BASE_2GB) ? BASE_2GB : TopOfLowRam;
- }
-
- //
- // address purpose size
- // ------------ -------- -------------------------
- // max(top, 2g) PCI MMIO 0xFC000000 - max(top, 2g)
- // 0xFC000000 gap 44 MB
- // 0xFEC00000 IO-APIC 4 KB
- // 0xFEC01000 gap 1020 KB
- // 0xFED00000 HPET 1 KB
- // 0xFED00400 gap 111 KB
- // 0xFED1C000 gap (PIIX4) / RCRB (ICH9) 16 KB
- // 0xFED20000 gap 896 KB
- // 0xFEE00000 LAPIC 1 MB
- //
- PciSize = 0xFC000000 - PciBase;
- AddIoMemoryBaseSizeHob (PciBase, PciSize);
- PcdStatus = PcdSet64S (PcdPciMmio32Base, PciBase);
- ASSERT_RETURN_ERROR (PcdStatus);
- PcdStatus = PcdSet64S (PcdPciMmio32Size, PciSize);
- ASSERT_RETURN_ERROR (PcdStatus);
-
- AddIoMemoryBaseSizeHob (0xFEC00000, SIZE_4KB);
- AddIoMemoryBaseSizeHob (0xFED00000, SIZE_1KB);
- if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
- AddIoMemoryBaseSizeHob (ICH9_ROOT_COMPLEX_BASE, SIZE_16KB);
- //
- // Note: there should be an
- //
- // AddIoMemoryBaseSizeHob (PciExBarBase, SIZE_256MB);
- //
- // call below, just like the one above for RCBA. However, Linux insists
- // that the MMCONFIG area be marked in the E820 or UEFI memory map as
- // "reserved memory" -- Linux does not content itself with a simple gap
- // in the memory map wherever the MCFG ACPI table points to.
- //
- // This appears to be a safety measure. The PCI Firmware Specification
- // (rev 3.1) says in 4.1.2. "MCFG Table Description": "The resources can
- // *optionally* be returned in [...] EFIGetMemoryMap as reserved memory
- // [...]". (Emphasis added here.)
- //
- // Normally we add memory resource descriptor HOBs in
- // QemuInitializeRam(), and pre-allocate from those with memory
- // allocation HOBs in InitializeRamRegions(). However, the MMCONFIG area
- // is most definitely not RAM; so, as an exception, cover it with
- // uncacheable reserved memory right here.
- //
- AddReservedMemoryBaseSizeHob (PciExBarBase, SIZE_256MB, FALSE);
- BuildMemoryAllocationHob (PciExBarBase, SIZE_256MB,
- EfiReservedMemoryType);
- }
- AddIoMemoryBaseSizeHob (PcdGet32(PcdCpuLocalApicBaseAddress), SIZE_1MB);
-
- //
- // On Q35, the IO Port space is available for PCI resource allocations from
- // 0x6000 up.
- //
- if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
- PciIoBase = 0x6000;
- PciIoSize = 0xA000;
- ASSERT ((ICH9_PMBASE_VALUE & 0xF000) < PciIoBase);
- }
- }
-
//
// Add PCI IO Port space available for PCI resource allocations.
//
@@ -278,71 +191,6 @@ MemMapInitialization (
ASSERT_RETURN_ERROR (PcdStatus);
}
-EFI_STATUS
-GetNamedFwCfgBoolean (
- IN CHAR8 *FwCfgFileName,
- OUT BOOLEAN *Setting
- )
-{
- EFI_STATUS Status;
- FIRMWARE_CONFIG_ITEM FwCfgItem;
- UINTN FwCfgSize;
- UINT8 Value[3];
-
- Status = QemuFwCfgFindFile (FwCfgFileName, &FwCfgItem, &FwCfgSize);
- if (EFI_ERROR (Status)) {
- return Status;
- }
- if (FwCfgSize > sizeof Value) {
- return EFI_BAD_BUFFER_SIZE;
- }
- QemuFwCfgSelectItem (FwCfgItem);
- QemuFwCfgReadBytes (FwCfgSize, Value);
-
- if ((FwCfgSize == 1) ||
- (FwCfgSize == 2 && Value[1] == '\n') ||
- (FwCfgSize == 3 && Value[1] == '\r' && Value[2] == '\n')) {
- switch (Value[0]) {
- case '0':
- case 'n':
- case 'N':
- *Setting = FALSE;
- return EFI_SUCCESS;
-
- case '1':
- case 'y':
- case 'Y':
- *Setting = TRUE;
- return EFI_SUCCESS;
-
- default:
- break;
- }
- }
- return EFI_PROTOCOL_ERROR;
-}
-
-#define UPDATE_BOOLEAN_PCD_FROM_FW_CFG(TokenName) \
- do { \
- BOOLEAN Setting; \
- RETURN_STATUS PcdStatus; \
- \
- if (!EFI_ERROR (GetNamedFwCfgBoolean ( \
- "opt/ovmf/" #TokenName, &Setting))) { \
- PcdStatus = PcdSetBoolS (TokenName, Setting); \
- ASSERT_RETURN_ERROR (PcdStatus); \
- } \
- } while (0)
-
-VOID
-NoexecDxeInitialization (
- VOID
- )
-{
- UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdPropertiesTableEnable);
- UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdSetNxForStack);
-}
-
VOID
PciExBarInitialization (
VOID
@@ -547,67 +395,6 @@ DebugDumpCmos (
}
-VOID
-S3Verification (
- VOID
- )
-{
-#if defined (MDE_CPU_X64)
- if (FeaturePcdGet (PcdSmmSmramRequire) && mS3Supported) {
- DEBUG ((EFI_D_ERROR,
- "%a: S3Resume2Pei doesn't support X64 PEI + SMM yet.\n", __FUNCTION__));
- DEBUG ((EFI_D_ERROR,
- "%a: Please disable S3 on the QEMU command line (see the README),\n",
- __FUNCTION__));
- DEBUG ((EFI_D_ERROR,
- "%a: or build OVMF with \"OvmfPkgIa32X64.dsc\".\n", __FUNCTION__));
- ASSERT (FALSE);
- CpuDeadLoop ();
- }
-#endif
-}
-
-
-/**
- Fetch the number of boot CPUs from QEMU and expose it to UefiCpuPkg modules.
- Set the mMaxCpuCount variable.
-**/
-VOID
-MaxCpuCountInitialization (
- VOID
- )
-{
- UINT16 ProcessorCount;
- RETURN_STATUS PcdStatus;
-
- QemuFwCfgSelectItem (QemuFwCfgItemSmpCpuCount);
- ProcessorCount = QemuFwCfgRead16 ();
- //
- // If the fw_cfg key or fw_cfg entirely is unavailable, load mMaxCpuCount
- // from the PCD default. No change to PCDs.
- //
- if (ProcessorCount == 0) {
- mMaxCpuCount = PcdGet32 (PcdCpuMaxLogicalProcessorNumber);
- return;
- }
- //
- // Otherwise, set mMaxCpuCount to the value reported by QEMU.
- //
- mMaxCpuCount = ProcessorCount;
- //
- // Additionally, tell UefiCpuPkg modules (a) the exact number of VCPUs, (b)
- // to wait, in the initial AP bringup, exactly as long as it takes for all of
- // the APs to report in. For this, we set the longest representable timeout
- // (approx. 71 minutes).
- //
- PcdStatus = PcdSet32S (PcdCpuMaxLogicalProcessorNumber, ProcessorCount);
- ASSERT_RETURN_ERROR (PcdStatus);
- PcdStatus = PcdSet32S (PcdCpuApInitTimeOutInMicroSeconds, MAX_UINT32);
- ASSERT_RETURN_ERROR (PcdStatus);
- DEBUG ((DEBUG_INFO, "%a: QEMU reports %d processor(s)\n", __FUNCTION__,
- ProcessorCount));
-}
-
/**
Perform Platform PEI initialization.
@@ -620,62 +407,43 @@ MaxCpuCountInitialization (
**/
EFI_STATUS
EFIAPI
-InitializePlatform (
+InitializeXenPlatform (
IN EFI_PEI_FILE_HANDLE FileHandle,
IN CONST EFI_PEI_SERVICES **PeiServices
)
{
- EFI_STATUS Status;
-
DEBUG ((DEBUG_INFO, "Platform PEIM Loaded\n"));
DebugDumpCmos ();
- XenDetect ();
-
- if (QemuFwCfgS3Enabled ()) {
- DEBUG ((EFI_D_INFO, "S3 support was detected on QEMU\n"));
- mS3Supported = TRUE;
- Status = PcdSetBoolS (PcdAcpiS3Enable, TRUE);
- ASSERT_EFI_ERROR (Status);
+ if (!XenDetect ()) {
+ DEBUG ((EFI_D_ERROR, "ERROR: Xen isn't detected\n"));
+ CpuDeadLoop ();
}
- S3Verification ();
BootModeInitialization ();
AddressWidthInitialization ();
- MaxCpuCountInitialization ();
//
// Query Host Bridge DID
//
mHostBridgeDevId = PciRead16 (OVMF_HOSTBRIDGE_DID);
- if (FeaturePcdGet (PcdSmmSmramRequire)) {
- Q35TsegMbytesInitialization ();
- }
-
PublishPeiMemory ();
InitializeRamRegions ();
- if (mXen) {
- DEBUG ((EFI_D_INFO, "Xen was detected\n"));
- InitializeXen ();
- }
+ InitializeXen ();
if (mBootMode != BOOT_ON_S3_RESUME) {
- if (!FeaturePcdGet (PcdSmmSmramRequire)) {
- ReserveEmuVariableNvStore ();
- }
+ ReserveEmuVariableNvStore ();
PeiFvInitialization ();
MemMapInitialization ();
- NoexecDxeInitialization ();
}
InstallClearCacheCallback ();
AmdSevInitialize ();
MiscInitialization ();
- InstallFeatureControlCallback ();
return EFI_SUCCESS;
}
diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
similarity index 94%
copy from OvmfPkg/PlatformPei/Xen.c
copy to OvmfPkg/XenPlatformPei/Xen.c
index ab38f97a67..7c82e5b69b 100644
--- a/OvmfPkg/PlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -3,6 +3,7 @@
Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
+ Copyright (c) 2019, Citrix Systems, Inc.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
@@ -34,8 +35,6 @@
#include "Platform.h"
#include "Xen.h"
-BOOLEAN mXen = FALSE;
-
STATIC UINT32 mXenLeaf = 0;
EFI_XEN_INFO mXenInfo;
@@ -143,7 +142,6 @@ XenDetect (
(UINT32 *) &Signature[8]);
if (!AsciiStrCmp ((CHAR8 *) Signature, "XenVMMXenVMM")) {
- mXen = TRUE;
return TRUE;
}
}
@@ -162,10 +160,6 @@ XenPublishRamRegions (
UINT32 E820EntriesCount;
EFI_STATUS Status;
- if (!mXen) {
- return;
- }
-
DEBUG ((EFI_D_INFO, "Using memory map provided by Xen\n"));
//
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 04/31] OvmfPkg: Introduce XenPlatformPei
@ 2019-04-10 10:37 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-10 10:37 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> A copy of OvmfPkg/PlatformPei without some of QEMU specific
> initialization, Xen does not support QemuFwCfg.
>
> This new module will be adjusted to accommodate Xen PVH.
>
> fw_cfg dependents that have been removed, which are dynamically skipped
> when running PlatformPei on Xen:
> - GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
> (experimental) "opt/ovmf/X-PciMmio64Mb" file
> - GetFirstNonAddress(): honoring the hotplug DIMM area
> ("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO
> aperture
> - NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
> PcdSetNxForStack are left constant FALSE (not set dynamically from
> fw_cfg "opt/ovmf/PcdXxxx")
> - MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
> not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
> PcdCpuMaxLogicalProcessorNumber is used intact and
> PcdCpuApInitTimeOutInMicroSeconds is never changed or used.
> - InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
> consulting "etc/system-states" via QemuFwCfgS3Enabled()).
> - InstallFeatureControlCallback(): the feature control MSR is not set
> from "etc/msr_feature_control"
> (also removed FeatureControl.c as there is nothing been executed)
>
> Also removed:
> - SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
> assumed FALSE) in PublishPeiMemory(),
> - QemuInitializeRam() entirely,
>
> Xen related changes:
> - Have removed the module variable mXen, as it should be always true.
> - Have the platform PEI initialization fails if Xen has not been
> detected.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenOvmf.dsc | 2 +-
> OvmfPkg/XenOvmf.fdf | 2 +-
> OvmfPkg/{PlatformPei/PlatformPei.inf => XenPlatformPei/XenPlatformPei.inf} | 28 +-
> OvmfPkg/{PlatformPei => XenPlatformPei}/Cmos.h | 2 +
> OvmfPkg/{PlatformPei => XenPlatformPei}/Platform.h | 13 +-
> OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.h | 0
> OvmfPkg/{PlatformPei => XenPlatformPei}/AmdSev.c | 30 +-
> OvmfPkg/{PlatformPei => XenPlatformPei}/ClearCache.c | 1 +
> OvmfPkg/{PlatformPei => XenPlatformPei}/Cmos.c | 2 +
> OvmfPkg/{PlatformPei => XenPlatformPei}/Fv.c | 26 +-
> OvmfPkg/XenPlatformPei/MemDetect.c | 427 ++++++++++++++++++++
> OvmfPkg/{PlatformPei => XenPlatformPei}/Platform.c | 246 +----------
> OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.c | 8 +-
> 13 files changed, 453 insertions(+), 334 deletions(-)
I reviewed this patch as follows:
- diffstat: only touchdes OvmfPkg/Xen*
- copyright notices in all new files: yes
- reviewed the output of:
git show -b --color --find-copies-harder -C40 anthony_v2~$((31-4))
It looks good to me, with two suggestions:
(1) I think you could always assume
mBootMode != BOOT_ON_S3_RESUME
I'm not saying you *should*, but you might prefer that, if it enabled
further simplifications. Up to you.
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 6161133fa8..7b8a1fdf6b 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -531,7 +531,7 @@ [Components]
> }
> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>
> - OvmfPkg/PlatformPei/PlatformPei.inf
> + OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> UefiCpuPkg/CpuMpPei/CpuMpPei.inf
>
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index 292cf4b492..295e30ca3f 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -158,7 +158,7 @@ [FV.PEIFV]
> INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
> INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
> INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
> -INF OvmfPkg/PlatformPei/PlatformPei.inf
> +INF OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> similarity index 69%
> copy from OvmfPkg/PlatformPei/PlatformPei.inf
> copy to OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> index 5c8dd0fe6d..c8d25c115f 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> @@ -3,6 +3,7 @@
> #
> # This module provides platform specific function to detect boot mode.
> # Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.<BR>
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> @@ -16,11 +17,11 @@
>
> [Defines]
> INF_VERSION = 0x00010005
> - BASE_NAME = PlatformPei
> - FILE_GUID = 222c386d-5abc-4fb4-b124-fbb82488acf4
> + BASE_NAME = XenPlatformPei
> + FILE_GUID = f112a6ee-993a-4f0b-8295-e52029d9b4ba
> MODULE_TYPE = PEIM
> VERSION_STRING = 1.0
> - ENTRY_POINT = InitializePlatform
> + ENTRY_POINT = InitializeXenPlatform
>
> #
> # The following information is for reference only and not required by the build tools.
> @@ -33,7 +34,6 @@ [Sources]
> ClearCache.c
> Cmos.c
> Cmos.h
> - FeatureControl.c
> Fv.c
> MemDetect.c
> Platform.c
> @@ -62,10 +62,7 @@ [LibraryClasses]
> PciLib
> ResourcePublicationLib
> PeiServicesLib
> - PeiServicesTablePointerLib
> PeimEntryPoint
> - QemuFwCfgLib
> - QemuFwCfgS3Lib
> MtrrLib
> MemEncryptSevLib
> PcdLib
> @@ -75,13 +72,8 @@ [Pcd]
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> - gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
> - gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
> - gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
> - gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
> - gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
> gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase
> gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize
> @@ -89,31 +81,19 @@ [Pcd]
> gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size
> gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base
> gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size
> - gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
> gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
> - gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
> - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
> gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
> gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
> gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
> - gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
> - gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
> - gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
> gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
> gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
>
> [FixedPcd]
> gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
>
> -[FeaturePcd]
> - gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> -
> [Ppis]
> gEfiPeiMasterBootModePpiGuid
> gEfiPeiMpServicesPpiGuid
> diff --git a/OvmfPkg/PlatformPei/Cmos.h b/OvmfPkg/XenPlatformPei/Cmos.h
> similarity index 92%
> copy from OvmfPkg/PlatformPei/Cmos.h
> copy to OvmfPkg/XenPlatformPei/Cmos.h
> index 949f884c2c..defe677122 100644
> --- a/OvmfPkg/PlatformPei/Cmos.h
> +++ b/OvmfPkg/XenPlatformPei/Cmos.h
> @@ -2,6 +2,8 @@
> PC/AT CMOS access routines
>
> Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> diff --git a/OvmfPkg/PlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
> similarity index 88%
> copy from OvmfPkg/PlatformPei/Platform.h
> copy to OvmfPkg/XenPlatformPei/Platform.h
> index b12a5c1f5f..6ccd5eb66c 100644
> --- a/OvmfPkg/PlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -2,6 +2,8 @@
> Platform PEI module include file.
>
> Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> @@ -78,11 +80,6 @@ PeiFvInitialization (
> VOID
> );
>
> -VOID
> -InstallFeatureControlCallback (
> - VOID
> - );
> -
> VOID
> InstallClearCacheCallback (
> VOID
> @@ -103,8 +100,6 @@ AmdSevInitialize (
> VOID
> );
>
> -extern BOOLEAN mXen;
> -
> VOID
> XenPublishRamRegions (
> VOID
> @@ -112,12 +107,8 @@ XenPublishRamRegions (
>
> extern EFI_BOOT_MODE mBootMode;
>
> -extern BOOLEAN mS3Supported;
> -
> extern UINT8 mPhysMemAddressWidth;
>
> -extern UINT32 mMaxCpuCount;
> -
> extern UINT16 mHostBridgeDevId;
>
> #endif // _PLATFORM_PEI_H_INCLUDED_
> diff --git a/OvmfPkg/PlatformPei/Xen.h b/OvmfPkg/XenPlatformPei/Xen.h
> similarity index 100%
> copy from OvmfPkg/PlatformPei/Xen.h
> copy to OvmfPkg/XenPlatformPei/Xen.h
> diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/XenPlatformPei/AmdSev.c
> similarity index 61%
> copy from OvmfPkg/PlatformPei/AmdSev.c
> copy to OvmfPkg/XenPlatformPei/AmdSev.c
> index 2e14eaf8c3..1a1f46291f 100644
> --- a/OvmfPkg/PlatformPei/AmdSev.c
> +++ b/OvmfPkg/XenPlatformPei/AmdSev.c
> @@ -2,6 +2,7 @@
> Initialize Secure Encrypted Virtualization (SEV) support
>
> Copyright (c) 2017, Advanced Micro Devices. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
>
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> @@ -16,7 +17,6 @@
> // The package level header files this module uses
> //
> #include <Library/DebugLib.h>
> -#include <Library/HobLib.h>
> #include <Library/MemEncryptSevLib.h>
> #include <Library/PcdLib.h>
> #include <PiPei.h>
> @@ -67,32 +67,4 @@ AmdSevInitialize (
> //
> PcdStatus = PcdSet32S (PcdOptionRomImageVerificationPolicy, 0x4);
> ASSERT_RETURN_ERROR (PcdStatus);
> -
> - //
> - // When SMM is required, cover the pages containing the initial SMRAM Save
> - // State Map with a memory allocation HOB:
> - //
> - // There's going to be a time interval between our decrypting those pages for
> - // SMBASE relocation and re-encrypting the same pages after SMBASE
> - // relocation. We shall ensure that the DXE phase stay away from those pages
> - // until after re-encryption, in order to prevent an information leak to the
> - // hypervisor.
> - //
> - if (FeaturePcdGet (PcdSmmSmramRequire) && (mBootMode != BOOT_ON_S3_RESUME)) {
> - RETURN_STATUS LocateMapStatus;
> - UINTN MapPagesBase;
> - UINTN MapPagesCount;
> -
> - LocateMapStatus = MemEncryptSevLocateInitialSmramSaveStateMapPages (
> - &MapPagesBase,
> - &MapPagesCount
> - );
> - ASSERT_RETURN_ERROR (LocateMapStatus);
> -
> - BuildMemoryAllocationHob (
> - MapPagesBase, // BaseAddress
> - EFI_PAGES_TO_SIZE (MapPagesCount), // Length
> - EfiBootServicesData // MemoryType
> - );
> - }
> }
> diff --git a/OvmfPkg/PlatformPei/ClearCache.c b/OvmfPkg/XenPlatformPei/ClearCache.c
> similarity index 95%
> copy from OvmfPkg/PlatformPei/ClearCache.c
> copy to OvmfPkg/XenPlatformPei/ClearCache.c
> index 7d15fd925c..78e22124e3 100644
> --- a/OvmfPkg/PlatformPei/ClearCache.c
> +++ b/OvmfPkg/XenPlatformPei/ClearCache.c
> @@ -6,6 +6,7 @@
> sake.
>
> Copyright (C) 2018, Red Hat, Inc.
> + Copyright (c) 2019, Citrix Systems, Inc.
>
> This program and the accompanying materials are licensed and made available
> under the terms and conditions of the BSD License which accompanies this
> diff --git a/OvmfPkg/PlatformPei/Cmos.c b/OvmfPkg/XenPlatformPei/Cmos.c
> similarity index 92%
> copy from OvmfPkg/PlatformPei/Cmos.c
> copy to OvmfPkg/XenPlatformPei/Cmos.c
> index 48ed2cb8f4..174ec773ec 100644
> --- a/OvmfPkg/PlatformPei/Cmos.c
> +++ b/OvmfPkg/XenPlatformPei/Cmos.c
> @@ -2,6 +2,8 @@
> PC/AT CMOS access routines
>
> Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> diff --git a/OvmfPkg/PlatformPei/Fv.c b/OvmfPkg/XenPlatformPei/Fv.c
> similarity index 72%
> copy from OvmfPkg/PlatformPei/Fv.c
> copy to OvmfPkg/XenPlatformPei/Fv.c
> index 248c585085..388e8768bf 100644
> --- a/OvmfPkg/PlatformPei/Fv.c
> +++ b/OvmfPkg/XenPlatformPei/Fv.c
> @@ -2,6 +2,8 @@
> Build FV related hobs for platform.
>
> Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> @@ -32,8 +34,6 @@ PeiFvInitialization (
> VOID
> )
> {
> - BOOLEAN SecureS3Needed;
> -
> DEBUG ((EFI_D_INFO, "Platform PEI Firmware Volume Initialization\n"));
>
> //
> @@ -44,7 +44,7 @@ PeiFvInitialization (
> BuildMemoryAllocationHob (
> PcdGet32 (PcdOvmfPeiMemFvBase),
> PcdGet32 (PcdOvmfPeiMemFvSize),
> - mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
> + EfiBootServicesData
> );
>
> //
> @@ -52,8 +52,6 @@ PeiFvInitialization (
> //
> BuildFvHob (PcdGet32 (PcdOvmfDxeMemFvBase), PcdGet32 (PcdOvmfDxeMemFvSize));
>
> - SecureS3Needed = mS3Supported && FeaturePcdGet (PcdSmmSmramRequire);
> -
> //
> // Create a memory allocation HOB for the DXE FV.
> //
> @@ -65,25 +63,9 @@ PeiFvInitialization (
> BuildMemoryAllocationHob (
> PcdGet32 (PcdOvmfDxeMemFvBase),
> PcdGet32 (PcdOvmfDxeMemFvSize),
> - SecureS3Needed ? EfiACPIMemoryNVS : EfiBootServicesData
> + EfiBootServicesData
> );
>
> - //
> - // Additionally, said decompression will use temporary memory above the end
> - // of DXEFV, so let's keep away the OS from there too.
> - //
> - if (SecureS3Needed) {
> - UINT32 DxeMemFvEnd;
> -
> - DxeMemFvEnd = PcdGet32 (PcdOvmfDxeMemFvBase) +
> - PcdGet32 (PcdOvmfDxeMemFvSize);
> - BuildMemoryAllocationHob (
> - DxeMemFvEnd,
> - PcdGet32 (PcdOvmfDecompressionScratchEnd) - DxeMemFvEnd,
> - EfiACPIMemoryNVS
> - );
> - }
> -
> //
> // Let PEI know about the DXE FV so it can find the DXE Core
> //
> diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c b/OvmfPkg/XenPlatformPei/MemDetect.c
> new file mode 100644
> index 0000000000..db3d387d1c
> --- /dev/null
> +++ b/OvmfPkg/XenPlatformPei/MemDetect.c
> @@ -0,0 +1,427 @@
> +/**@file
> + Memory Detection for Virtual Machines.
> +
> + Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> + This program and the accompanying materials
> + are licensed and made available under the terms and conditions of the BSD License
> + which accompanies this distribution. The full text of the license may be found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +Module Name:
> +
> + MemDetect.c
> +
> +**/
> +
> +//
> +// The package level header files this module uses
> +//
> +#include <IndustryStandard/Q35MchIch9.h>
> +#include <PiPei.h>
> +
> +//
> +// The Library classes this module consumes
> +//
> +#include <Library/BaseLib.h>
> +#include <Library/BaseMemoryLib.h>
> +#include <Library/DebugLib.h>
> +#include <Library/HobLib.h>
> +#include <Library/IoLib.h>
> +#include <Library/PcdLib.h>
> +#include <Library/PciLib.h>
> +#include <Library/PeimEntryPoint.h>
> +#include <Library/ResourcePublicationLib.h>
> +
> +#include "Platform.h"
> +#include "Cmos.h"
> +
> +UINT8 mPhysMemAddressWidth;
> +
> +STATIC UINT32 mS3AcpiReservedMemoryBase;
> +STATIC UINT32 mS3AcpiReservedMemorySize;
> +
> +STATIC UINT16 mQ35TsegMbytes;
> +
> +VOID
> +Q35TsegMbytesInitialization (
> + VOID
> + )
> +{
> + UINT16 ExtendedTsegMbytes;
> + RETURN_STATUS PcdStatus;
> +
> + if (mHostBridgeDevId != INTEL_Q35_MCH_DEVICE_ID) {
> + DEBUG ((
> + DEBUG_ERROR,
> + "%a: no TSEG (SMRAM) on host bridge DID=0x%04x; "
> + "only DID=0x%04x (Q35) is supported\n",
> + __FUNCTION__,
> + mHostBridgeDevId,
> + INTEL_Q35_MCH_DEVICE_ID
> + ));
> + ASSERT (FALSE);
> + CpuDeadLoop ();
> + }
> +
> + //
> + // Check if QEMU offers an extended TSEG.
> + //
> + // This can be seen from writing MCH_EXT_TSEG_MB_QUERY to the MCH_EXT_TSEG_MB
> + // register, and reading back the register.
> + //
> + // On a QEMU machine type that does not offer an extended TSEG, the initial
> + // write overwrites whatever value a malicious guest OS may have placed in
> + // the (unimplemented) register, before entering S3 or rebooting.
> + // Subsequently, the read returns MCH_EXT_TSEG_MB_QUERY unchanged.
> + //
> + // On a QEMU machine type that offers an extended TSEG, the initial write
> + // triggers an update to the register. Subsequently, the value read back
> + // (which is guaranteed to differ from MCH_EXT_TSEG_MB_QUERY) tells us the
> + // number of megabytes.
> + //
> + PciWrite16 (DRAMC_REGISTER_Q35 (MCH_EXT_TSEG_MB), MCH_EXT_TSEG_MB_QUERY);
> + ExtendedTsegMbytes = PciRead16 (DRAMC_REGISTER_Q35 (MCH_EXT_TSEG_MB));
> + if (ExtendedTsegMbytes == MCH_EXT_TSEG_MB_QUERY) {
> + mQ35TsegMbytes = PcdGet16 (PcdQ35TsegMbytes);
> + return;
> + }
> +
> + DEBUG ((
> + DEBUG_INFO,
> + "%a: QEMU offers an extended TSEG (%d MB)\n",
> + __FUNCTION__,
> + ExtendedTsegMbytes
> + ));
> + PcdStatus = PcdSet16S (PcdQ35TsegMbytes, ExtendedTsegMbytes);
> + ASSERT_RETURN_ERROR (PcdStatus);
> + mQ35TsegMbytes = ExtendedTsegMbytes;
> +}
> +
> +
> +UINT32
> +GetSystemMemorySizeBelow4gb (
> + VOID
> + )
> +{
> + UINT8 Cmos0x34;
> + UINT8 Cmos0x35;
> +
> + //
> + // CMOS 0x34/0x35 specifies the system memory above 16 MB.
> + // * CMOS(0x35) is the high byte
> + // * CMOS(0x34) is the low byte
> + // * The size is specified in 64kb chunks
> + // * Since this is memory above 16MB, the 16MB must be added
> + // into the calculation to get the total memory size.
> + //
> +
> + Cmos0x34 = (UINT8) CmosRead8 (0x34);
> + Cmos0x35 = (UINT8) CmosRead8 (0x35);
> +
> + return (UINT32) (((UINTN)((Cmos0x35 << 8) + Cmos0x34) << 16) + SIZE_16MB);
> +}
> +
> +
> +STATIC
> +UINT64
> +GetSystemMemorySizeAbove4gb (
> + )
> +{
> + UINT32 Size;
> + UINTN CmosIndex;
> +
> + //
> + // CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
> + // * CMOS(0x5d) is the most significant size byte
> + // * CMOS(0x5c) is the middle size byte
> + // * CMOS(0x5b) is the least significant size byte
> + // * The size is specified in 64kb chunks
> + //
> +
> + Size = 0;
> + for (CmosIndex = 0x5d; CmosIndex >= 0x5b; CmosIndex--) {
> + Size = (UINT32) (Size << 8) + (UINT32) CmosRead8 (CmosIndex);
> + }
> +
> + return LShiftU64 (Size, 16);
> +}
> +
> +
> +/**
> + Return the highest address that DXE could possibly use, plus one.
> +**/
> +STATIC
> +UINT64
> +GetFirstNonAddress (
> + VOID
> + )
> +{
> + UINT64 FirstNonAddress;
> + UINT64 Pci64Base, Pci64Size;
> + RETURN_STATUS PcdStatus;
> +
> + FirstNonAddress = BASE_4GB + GetSystemMemorySizeAbove4gb ();
> +
> + //
> + // If DXE is 32-bit, then we're done; PciBusDxe will degrade 64-bit MMIO
> + // resources to 32-bit anyway. See DegradeResource() in
> + // "PciResourceSupport.c".
> + //
> +#ifdef MDE_CPU_IA32
> + if (!FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
> + return FirstNonAddress;
> + }
> +#endif
> +
> + //
> + // 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);
> +
> + if (Pci64Size == 0) {
> + if (mBootMode != BOOT_ON_S3_RESUME) {
> + DEBUG ((EFI_D_INFO, "%a: disabling 64-bit PCI host aperture\n",
> + __FUNCTION__));
> + PcdStatus = PcdSet64S (PcdPciMmio64Size, 0);
> + ASSERT_RETURN_ERROR (PcdStatus);
> + }
> +
> + //
> + // There's nothing more to do; the amount of memory above 4GB fully
> + // determines the highest address plus one. The memory hotplug area (see
> + // below) plays no role for the firmware in this case.
> + //
> + return FirstNonAddress;
> + }
> +
> + //
> + // SeaBIOS aligns both boundaries of the 64-bit PCI host aperture to 1GB, so
> + // that the host can map it with 1GB hugepages. Follow suit.
> + //
> + Pci64Base = ALIGN_VALUE (FirstNonAddress, (UINT64)SIZE_1GB);
> + Pci64Size = ALIGN_VALUE (Pci64Size, (UINT64)SIZE_1GB);
> +
> + //
> + // The 64-bit PCI host aperture should also be "naturally" aligned. The
> + // alignment is determined by rounding the size of the aperture down to the
> + // next smaller or equal power of two. That is, align the aperture by the
> + // largest BAR size that can fit into it.
> + //
> + Pci64Base = ALIGN_VALUE (Pci64Base, GetPowerOfTwo64 (Pci64Size));
> +
> + if (mBootMode != BOOT_ON_S3_RESUME) {
> + //
> + // The core PciHostBridgeDxe driver will automatically add this range to
> + // the GCD memory space map through our PciHostBridgeLib instance; here we
> + // only need to set the PCDs.
> + //
> + PcdStatus = PcdSet64S (PcdPciMmio64Base, Pci64Base);
> + ASSERT_RETURN_ERROR (PcdStatus);
> + PcdStatus = PcdSet64S (PcdPciMmio64Size, Pci64Size);
> + ASSERT_RETURN_ERROR (PcdStatus);
> +
> + DEBUG ((EFI_D_INFO, "%a: Pci64Base=0x%Lx Pci64Size=0x%Lx\n",
> + __FUNCTION__, Pci64Base, Pci64Size));
> + }
> +
> + //
> + // The useful address space ends with the 64-bit PCI host aperture.
> + //
> + FirstNonAddress = Pci64Base + Pci64Size;
> + return FirstNonAddress;
> +}
> +
> +
> +/**
> + Initialize the mPhysMemAddressWidth variable, based on guest RAM size.
> +**/
> +VOID
> +AddressWidthInitialization (
> + VOID
> + )
> +{
> + UINT64 FirstNonAddress;
> +
> + //
> + // As guest-physical memory size grows, the permanent PEI RAM requirements
> + // are dominated by the identity-mapping page tables built by the DXE IPL.
> + // The DXL IPL keys off of the physical address bits advertized in the CPU
> + // HOB. To conserve memory, we calculate the minimum address width here.
> + //
> + FirstNonAddress = GetFirstNonAddress ();
> + mPhysMemAddressWidth = (UINT8)HighBitSet64 (FirstNonAddress);
> +
> + //
> + // If FirstNonAddress is not an integral power of two, then we need an
> + // additional bit.
> + //
> + if ((FirstNonAddress & (FirstNonAddress - 1)) != 0) {
> + ++mPhysMemAddressWidth;
> + }
> +
> + //
> + // The minimum address width is 36 (covers up to and excluding 64 GB, which
> + // is the maximum for Ia32 + PAE). The theoretical architecture maximum for
> + // X64 long mode is 52 bits, but the DXE IPL clamps that down to 48 bits. We
> + // can simply assert that here, since 48 bits are good enough for 256 TB.
> + //
> + if (mPhysMemAddressWidth <= 36) {
> + mPhysMemAddressWidth = 36;
> + }
> + ASSERT (mPhysMemAddressWidth <= 48);
> +}
> +
> +
> +/**
> + Calculate the cap for the permanent PEI memory.
> +**/
> +STATIC
> +UINT32
> +GetPeiMemoryCap (
> + VOID
> + )
> +{
> + BOOLEAN Page1GSupport;
> + UINT32 RegEax;
> + UINT32 RegEdx;
> + UINT32 Pml4Entries;
> + UINT32 PdpEntries;
> + UINTN TotalPages;
> +
> + //
> + // If DXE is 32-bit, then just return the traditional 64 MB cap.
> + //
> +#ifdef MDE_CPU_IA32
> + if (!FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
> + return SIZE_64MB;
> + }
> +#endif
> +
> + //
> + // Dependent on physical address width, PEI memory allocations can be
> + // dominated by the page tables built for 64-bit DXE. So we key the cap off
> + // of those. The code below is based on CreateIdentityMappingPageTables() in
> + // "MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c".
> + //
> + Page1GSupport = FALSE;
> + if (PcdGetBool (PcdUse1GPageTable)) {
> + AsmCpuid (0x80000000, &RegEax, NULL, NULL, NULL);
> + if (RegEax >= 0x80000001) {
> + AsmCpuid (0x80000001, NULL, NULL, NULL, &RegEdx);
> + if ((RegEdx & BIT26) != 0) {
> + Page1GSupport = TRUE;
> + }
> + }
> + }
> +
> + if (mPhysMemAddressWidth <= 39) {
> + Pml4Entries = 1;
> + PdpEntries = 1 << (mPhysMemAddressWidth - 30);
> + ASSERT (PdpEntries <= 0x200);
> + } else {
> + Pml4Entries = 1 << (mPhysMemAddressWidth - 39);
> + ASSERT (Pml4Entries <= 0x200);
> + PdpEntries = 512;
> + }
> +
> + TotalPages = Page1GSupport ? Pml4Entries + 1 :
> + (PdpEntries + 1) * Pml4Entries + 1;
> + ASSERT (TotalPages <= 0x40201);
> +
> + //
> + // Add 64 MB for miscellaneous allocations. Note that for
> + // mPhysMemAddressWidth values close to 36, the cap will actually be
> + // dominated by this increment.
> + //
> + return (UINT32)(EFI_PAGES_TO_SIZE (TotalPages) + SIZE_64MB);
> +}
> +
> +
> +/**
> + Publish PEI core memory
> +
> + @return EFI_SUCCESS The PEIM initialized successfully.
> +
> +**/
> +EFI_STATUS
> +PublishPeiMemory (
> + VOID
> + )
> +{
> + EFI_STATUS Status;
> + EFI_PHYSICAL_ADDRESS MemoryBase;
> + UINT64 MemorySize;
> + UINT32 LowerMemorySize;
> + UINT32 PeiMemoryCap;
> +
> + LowerMemorySize = GetSystemMemorySizeBelow4gb ();
> +
> + if (mBootMode == BOOT_ON_S3_RESUME) {
> + MemoryBase = mS3AcpiReservedMemoryBase;
> + MemorySize = mS3AcpiReservedMemorySize;
> + } else {
> + PeiMemoryCap = GetPeiMemoryCap ();
> + DEBUG ((EFI_D_INFO, "%a: mPhysMemAddressWidth=%d PeiMemoryCap=%u KB\n",
> + __FUNCTION__, mPhysMemAddressWidth, PeiMemoryCap >> 10));
> +
> + //
> + // Determine the range of memory to use during PEI
> + //
> + MemoryBase =
> + PcdGet32 (PcdOvmfDxeMemFvBase) + PcdGet32 (PcdOvmfDxeMemFvSize);
> + MemorySize = LowerMemorySize - MemoryBase;
> + if (MemorySize > PeiMemoryCap) {
> + MemoryBase = LowerMemorySize - PeiMemoryCap;
> + MemorySize = PeiMemoryCap;
> + }
> + }
> +
> + //
> + // Publish this memory to the PEI Core
> + //
> + Status = PublishSystemMemory(MemoryBase, MemorySize);
> + ASSERT_EFI_ERROR (Status);
> +
> + return Status;
> +}
> +
> +
> +/**
> + Publish system RAM and reserve memory regions
> +
> +**/
> +VOID
> +InitializeRamRegions (
> + VOID
> + )
> +{
> + XenPublishRamRegions ();
> +
> + if (mBootMode != BOOT_ON_S3_RESUME) {
> + //
> + // Reserve the lock box storage area
> + //
> + // Since this memory range will be used on S3 resume, it must be
> + // reserved as ACPI NVS.
> + //
> + // If S3 is unsupported, then various drivers might still write to the
> + // LockBox area. We ought to prevent DXE from serving allocation requests
> + // such that they would overlap the LockBox storage.
> + //
> + ZeroMem (
> + (VOID*)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
> + (UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize)
> + );
> + BuildMemoryAllocationHob (
> + (EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
> + (UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize),
> + EfiBootServicesData
> + );
> + }
> +}
> diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
> similarity index 56%
> copy from OvmfPkg/PlatformPei/Platform.c
> copy to OvmfPkg/XenPlatformPei/Platform.c
> index 22139a64cb..2d567a4760 100644
> --- a/OvmfPkg/PlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -3,6 +3,7 @@
>
> Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
> Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
> + Copyright (c) 2019, Citrix Systems, Inc.
>
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> @@ -31,8 +32,6 @@
> #include <Library/PciLib.h>
> #include <Library/PeimEntryPoint.h>
> #include <Library/PeiServicesLib.h>
> -#include <Library/QemuFwCfgLib.h>
> -#include <Library/QemuFwCfgS3Lib.h>
> #include <Library/ResourcePublicationLib.h>
> #include <Guid/MemoryTypeInformation.h>
> #include <Ppi/MasterBootMode.h>
> @@ -67,9 +66,6 @@ UINT16 mHostBridgeDevId;
>
> EFI_BOOT_MODE mBootMode = BOOT_WITH_FULL_CONFIGURATION;
>
> -BOOLEAN mS3Supported = FALSE;
> -
> -UINT32 mMaxCpuCount;
>
> VOID
> AddIoMemoryBaseSizeHob (
> @@ -179,89 +175,6 @@ MemMapInitialization (
> //
> AddIoMemoryRangeHob (0x0A0000, BASE_1MB);
>
> - if (!mXen) {
> - UINT32 TopOfLowRam;
> - UINT64 PciExBarBase;
> - UINT32 PciBase;
> - UINT32 PciSize;
> -
> - TopOfLowRam = GetSystemMemorySizeBelow4gb ();
> - PciExBarBase = 0;
> - if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
> - //
> - // The MMCONFIG area is expected to fall between the top of low RAM and
> - // the base of the 32-bit PCI host aperture.
> - //
> - PciExBarBase = FixedPcdGet64 (PcdPciExpressBaseAddress);
> - ASSERT (TopOfLowRam <= PciExBarBase);
> - ASSERT (PciExBarBase <= MAX_UINT32 - SIZE_256MB);
> - PciBase = (UINT32)(PciExBarBase + SIZE_256MB);
> - } else {
> - PciBase = (TopOfLowRam < BASE_2GB) ? BASE_2GB : TopOfLowRam;
> - }
> -
> - //
> - // address purpose size
> - // ------------ -------- -------------------------
> - // max(top, 2g) PCI MMIO 0xFC000000 - max(top, 2g)
> - // 0xFC000000 gap 44 MB
> - // 0xFEC00000 IO-APIC 4 KB
> - // 0xFEC01000 gap 1020 KB
> - // 0xFED00000 HPET 1 KB
> - // 0xFED00400 gap 111 KB
> - // 0xFED1C000 gap (PIIX4) / RCRB (ICH9) 16 KB
> - // 0xFED20000 gap 896 KB
> - // 0xFEE00000 LAPIC 1 MB
> - //
> - PciSize = 0xFC000000 - PciBase;
> - AddIoMemoryBaseSizeHob (PciBase, PciSize);
> - PcdStatus = PcdSet64S (PcdPciMmio32Base, PciBase);
> - ASSERT_RETURN_ERROR (PcdStatus);
> - PcdStatus = PcdSet64S (PcdPciMmio32Size, PciSize);
> - ASSERT_RETURN_ERROR (PcdStatus);
> -
> - AddIoMemoryBaseSizeHob (0xFEC00000, SIZE_4KB);
> - AddIoMemoryBaseSizeHob (0xFED00000, SIZE_1KB);
> - if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
> - AddIoMemoryBaseSizeHob (ICH9_ROOT_COMPLEX_BASE, SIZE_16KB);
> - //
> - // Note: there should be an
> - //
> - // AddIoMemoryBaseSizeHob (PciExBarBase, SIZE_256MB);
> - //
> - // call below, just like the one above for RCBA. However, Linux insists
> - // that the MMCONFIG area be marked in the E820 or UEFI memory map as
> - // "reserved memory" -- Linux does not content itself with a simple gap
> - // in the memory map wherever the MCFG ACPI table points to.
> - //
> - // This appears to be a safety measure. The PCI Firmware Specification
> - // (rev 3.1) says in 4.1.2. "MCFG Table Description": "The resources can
> - // *optionally* be returned in [...] EFIGetMemoryMap as reserved memory
> - // [...]". (Emphasis added here.)
> - //
> - // Normally we add memory resource descriptor HOBs in
> - // QemuInitializeRam(), and pre-allocate from those with memory
> - // allocation HOBs in InitializeRamRegions(). However, the MMCONFIG area
> - // is most definitely not RAM; so, as an exception, cover it with
> - // uncacheable reserved memory right here.
> - //
> - AddReservedMemoryBaseSizeHob (PciExBarBase, SIZE_256MB, FALSE);
> - BuildMemoryAllocationHob (PciExBarBase, SIZE_256MB,
> - EfiReservedMemoryType);
> - }
> - AddIoMemoryBaseSizeHob (PcdGet32(PcdCpuLocalApicBaseAddress), SIZE_1MB);
> -
> - //
> - // On Q35, the IO Port space is available for PCI resource allocations from
> - // 0x6000 up.
> - //
> - if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
> - PciIoBase = 0x6000;
> - PciIoSize = 0xA000;
> - ASSERT ((ICH9_PMBASE_VALUE & 0xF000) < PciIoBase);
> - }
> - }
> -
> //
> // Add PCI IO Port space available for PCI resource allocations.
> //
> @@ -278,71 +191,6 @@ MemMapInitialization (
> ASSERT_RETURN_ERROR (PcdStatus);
> }
>
> -EFI_STATUS
> -GetNamedFwCfgBoolean (
> - IN CHAR8 *FwCfgFileName,
> - OUT BOOLEAN *Setting
> - )
> -{
> - EFI_STATUS Status;
> - FIRMWARE_CONFIG_ITEM FwCfgItem;
> - UINTN FwCfgSize;
> - UINT8 Value[3];
> -
> - Status = QemuFwCfgFindFile (FwCfgFileName, &FwCfgItem, &FwCfgSize);
> - if (EFI_ERROR (Status)) {
> - return Status;
> - }
> - if (FwCfgSize > sizeof Value) {
> - return EFI_BAD_BUFFER_SIZE;
> - }
> - QemuFwCfgSelectItem (FwCfgItem);
> - QemuFwCfgReadBytes (FwCfgSize, Value);
> -
> - if ((FwCfgSize == 1) ||
> - (FwCfgSize == 2 && Value[1] == '\n') ||
> - (FwCfgSize == 3 && Value[1] == '\r' && Value[2] == '\n')) {
> - switch (Value[0]) {
> - case '0':
> - case 'n':
> - case 'N':
> - *Setting = FALSE;
> - return EFI_SUCCESS;
> -
> - case '1':
> - case 'y':
> - case 'Y':
> - *Setting = TRUE;
> - return EFI_SUCCESS;
> -
> - default:
> - break;
> - }
> - }
> - return EFI_PROTOCOL_ERROR;
> -}
> -
> -#define UPDATE_BOOLEAN_PCD_FROM_FW_CFG(TokenName) \
> - do { \
> - BOOLEAN Setting; \
> - RETURN_STATUS PcdStatus; \
> - \
> - if (!EFI_ERROR (GetNamedFwCfgBoolean ( \
> - "opt/ovmf/" #TokenName, &Setting))) { \
> - PcdStatus = PcdSetBoolS (TokenName, Setting); \
> - ASSERT_RETURN_ERROR (PcdStatus); \
> - } \
> - } while (0)
> -
> -VOID
> -NoexecDxeInitialization (
> - VOID
> - )
> -{
> - UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdPropertiesTableEnable);
> - UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdSetNxForStack);
> -}
> -
> VOID
> PciExBarInitialization (
> VOID
> @@ -547,67 +395,6 @@ DebugDumpCmos (
> }
>
>
> -VOID
> -S3Verification (
> - VOID
> - )
> -{
> -#if defined (MDE_CPU_X64)
> - if (FeaturePcdGet (PcdSmmSmramRequire) && mS3Supported) {
> - DEBUG ((EFI_D_ERROR,
> - "%a: S3Resume2Pei doesn't support X64 PEI + SMM yet.\n", __FUNCTION__));
> - DEBUG ((EFI_D_ERROR,
> - "%a: Please disable S3 on the QEMU command line (see the README),\n",
> - __FUNCTION__));
> - DEBUG ((EFI_D_ERROR,
> - "%a: or build OVMF with \"OvmfPkgIa32X64.dsc\".\n", __FUNCTION__));
> - ASSERT (FALSE);
> - CpuDeadLoop ();
> - }
> -#endif
> -}
> -
> -
> -/**
> - Fetch the number of boot CPUs from QEMU and expose it to UefiCpuPkg modules.
> - Set the mMaxCpuCount variable.
> -**/
> -VOID
> -MaxCpuCountInitialization (
> - VOID
> - )
> -{
> - UINT16 ProcessorCount;
> - RETURN_STATUS PcdStatus;
> -
> - QemuFwCfgSelectItem (QemuFwCfgItemSmpCpuCount);
> - ProcessorCount = QemuFwCfgRead16 ();
> - //
> - // If the fw_cfg key or fw_cfg entirely is unavailable, load mMaxCpuCount
> - // from the PCD default. No change to PCDs.
> - //
> - if (ProcessorCount == 0) {
> - mMaxCpuCount = PcdGet32 (PcdCpuMaxLogicalProcessorNumber);
> - return;
> - }
> - //
> - // Otherwise, set mMaxCpuCount to the value reported by QEMU.
> - //
> - mMaxCpuCount = ProcessorCount;
> - //
> - // Additionally, tell UefiCpuPkg modules (a) the exact number of VCPUs, (b)
> - // to wait, in the initial AP bringup, exactly as long as it takes for all of
> - // the APs to report in. For this, we set the longest representable timeout
> - // (approx. 71 minutes).
> - //
> - PcdStatus = PcdSet32S (PcdCpuMaxLogicalProcessorNumber, ProcessorCount);
> - ASSERT_RETURN_ERROR (PcdStatus);
> - PcdStatus = PcdSet32S (PcdCpuApInitTimeOutInMicroSeconds, MAX_UINT32);
> - ASSERT_RETURN_ERROR (PcdStatus);
> - DEBUG ((DEBUG_INFO, "%a: QEMU reports %d processor(s)\n", __FUNCTION__,
> - ProcessorCount));
> -}
> -
>
> /**
> Perform Platform PEI initialization.
> @@ -620,62 +407,43 @@ MaxCpuCountInitialization (
> **/
> EFI_STATUS
> EFIAPI
> -InitializePlatform (
> +InitializeXenPlatform (
> IN EFI_PEI_FILE_HANDLE FileHandle,
> IN CONST EFI_PEI_SERVICES **PeiServices
> )
> {
> - EFI_STATUS Status;
> -
> DEBUG ((DEBUG_INFO, "Platform PEIM Loaded\n"));
>
> DebugDumpCmos ();
>
> - XenDetect ();
> -
> - if (QemuFwCfgS3Enabled ()) {
> - DEBUG ((EFI_D_INFO, "S3 support was detected on QEMU\n"));
> - mS3Supported = TRUE;
> - Status = PcdSetBoolS (PcdAcpiS3Enable, TRUE);
> - ASSERT_EFI_ERROR (Status);
> + if (!XenDetect ()) {
> + DEBUG ((EFI_D_ERROR, "ERROR: Xen isn't detected\n"));
> + CpuDeadLoop ();
> }
(2) This is brand new code.
- In new code, we should use DEBUG_xxx, not EFI_D_xxx.
- Please insert an "ASSERT (FALSE);" before CpuDeadLoop (). The current
code is not wrong, but assertion failures can be configured to have a
disposition different from an internal CpuDeadLoop(), and
ASSERT(FALSE) + CpuDeadLoop() is both safe and preserves this
configurability. It's just an edk2 pattern that was recommended to me
earlier and I've followed it too since.
With (2) updated (and (1) is up to you):
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
I'll try to continue reviewing the series tomorrow.
Thanks,
Laszlo
>
> - S3Verification ();
> BootModeInitialization ();
> AddressWidthInitialization ();
> - MaxCpuCountInitialization ();
>
> //
> // Query Host Bridge DID
> //
> mHostBridgeDevId = PciRead16 (OVMF_HOSTBRIDGE_DID);
>
> - if (FeaturePcdGet (PcdSmmSmramRequire)) {
> - Q35TsegMbytesInitialization ();
> - }
> -
> PublishPeiMemory ();
>
> InitializeRamRegions ();
>
> - if (mXen) {
> - DEBUG ((EFI_D_INFO, "Xen was detected\n"));
> - InitializeXen ();
> - }
> + InitializeXen ();
>
> if (mBootMode != BOOT_ON_S3_RESUME) {
> - if (!FeaturePcdGet (PcdSmmSmramRequire)) {
> - ReserveEmuVariableNvStore ();
> - }
> + ReserveEmuVariableNvStore ();
> PeiFvInitialization ();
> MemMapInitialization ();
> - NoexecDxeInitialization ();
> }
>
> InstallClearCacheCallback ();
> AmdSevInitialize ();
> MiscInitialization ();
> - InstallFeatureControlCallback ();
>
> return EFI_SUCCESS;
> }
> diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> similarity index 94%
> copy from OvmfPkg/PlatformPei/Xen.c
> copy to OvmfPkg/XenPlatformPei/Xen.c
> index ab38f97a67..7c82e5b69b 100644
> --- a/OvmfPkg/PlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -3,6 +3,7 @@
>
> Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
> Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
> + Copyright (c) 2019, Citrix Systems, Inc.
>
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> @@ -34,8 +35,6 @@
> #include "Platform.h"
> #include "Xen.h"
>
> -BOOLEAN mXen = FALSE;
> -
> STATIC UINT32 mXenLeaf = 0;
>
> EFI_XEN_INFO mXenInfo;
> @@ -143,7 +142,6 @@ XenDetect (
> (UINT32 *) &Signature[8]);
>
> if (!AsciiStrCmp ((CHAR8 *) Signature, "XenVMMXenVMM")) {
> - mXen = TRUE;
> return TRUE;
> }
> }
> @@ -162,10 +160,6 @@ XenPublishRamRegions (
> UINT32 E820EntriesCount;
> EFI_STATUS Status;
>
> - if (!mXen) {
> - return;
> - }
> -
> DEBUG ((EFI_D_INFO, "Using memory map provided by Xen\n"));
>
> //
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 04/31] OvmfPkg: Introduce XenPlatformPei
@ 2019-04-10 10:37 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-10 10:37 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> A copy of OvmfPkg/PlatformPei without some of QEMU specific
> initialization, Xen does not support QemuFwCfg.
>
> This new module will be adjusted to accommodate Xen PVH.
>
> fw_cfg dependents that have been removed, which are dynamically skipped
> when running PlatformPei on Xen:
> - GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
> (experimental) "opt/ovmf/X-PciMmio64Mb" file
> - GetFirstNonAddress(): honoring the hotplug DIMM area
> ("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO
> aperture
> - NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
> PcdSetNxForStack are left constant FALSE (not set dynamically from
> fw_cfg "opt/ovmf/PcdXxxx")
> - MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
> not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
> PcdCpuMaxLogicalProcessorNumber is used intact and
> PcdCpuApInitTimeOutInMicroSeconds is never changed or used.
> - InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
> consulting "etc/system-states" via QemuFwCfgS3Enabled()).
> - InstallFeatureControlCallback(): the feature control MSR is not set
> from "etc/msr_feature_control"
> (also removed FeatureControl.c as there is nothing been executed)
>
> Also removed:
> - SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
> assumed FALSE) in PublishPeiMemory(),
> - QemuInitializeRam() entirely,
>
> Xen related changes:
> - Have removed the module variable mXen, as it should be always true.
> - Have the platform PEI initialization fails if Xen has not been
> detected.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenOvmf.dsc | 2 +-
> OvmfPkg/XenOvmf.fdf | 2 +-
> OvmfPkg/{PlatformPei/PlatformPei.inf => XenPlatformPei/XenPlatformPei.inf} | 28 +-
> OvmfPkg/{PlatformPei => XenPlatformPei}/Cmos.h | 2 +
> OvmfPkg/{PlatformPei => XenPlatformPei}/Platform.h | 13 +-
> OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.h | 0
> OvmfPkg/{PlatformPei => XenPlatformPei}/AmdSev.c | 30 +-
> OvmfPkg/{PlatformPei => XenPlatformPei}/ClearCache.c | 1 +
> OvmfPkg/{PlatformPei => XenPlatformPei}/Cmos.c | 2 +
> OvmfPkg/{PlatformPei => XenPlatformPei}/Fv.c | 26 +-
> OvmfPkg/XenPlatformPei/MemDetect.c | 427 ++++++++++++++++++++
> OvmfPkg/{PlatformPei => XenPlatformPei}/Platform.c | 246 +----------
> OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.c | 8 +-
> 13 files changed, 453 insertions(+), 334 deletions(-)
I reviewed this patch as follows:
- diffstat: only touchdes OvmfPkg/Xen*
- copyright notices in all new files: yes
- reviewed the output of:
git show -b --color --find-copies-harder -C40 anthony_v2~$((31-4))
It looks good to me, with two suggestions:
(1) I think you could always assume
mBootMode != BOOT_ON_S3_RESUME
I'm not saying you *should*, but you might prefer that, if it enabled
further simplifications. Up to you.
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 6161133fa8..7b8a1fdf6b 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -531,7 +531,7 @@ [Components]
> }
> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>
> - OvmfPkg/PlatformPei/PlatformPei.inf
> + OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> UefiCpuPkg/CpuMpPei/CpuMpPei.inf
>
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index 292cf4b492..295e30ca3f 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -158,7 +158,7 @@ [FV.PEIFV]
> INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
> INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
> INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
> -INF OvmfPkg/PlatformPei/PlatformPei.inf
> +INF OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> similarity index 69%
> copy from OvmfPkg/PlatformPei/PlatformPei.inf
> copy to OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> index 5c8dd0fe6d..c8d25c115f 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> @@ -3,6 +3,7 @@
> #
> # This module provides platform specific function to detect boot mode.
> # Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.<BR>
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> @@ -16,11 +17,11 @@
>
> [Defines]
> INF_VERSION = 0x00010005
> - BASE_NAME = PlatformPei
> - FILE_GUID = 222c386d-5abc-4fb4-b124-fbb82488acf4
> + BASE_NAME = XenPlatformPei
> + FILE_GUID = f112a6ee-993a-4f0b-8295-e52029d9b4ba
> MODULE_TYPE = PEIM
> VERSION_STRING = 1.0
> - ENTRY_POINT = InitializePlatform
> + ENTRY_POINT = InitializeXenPlatform
>
> #
> # The following information is for reference only and not required by the build tools.
> @@ -33,7 +34,6 @@ [Sources]
> ClearCache.c
> Cmos.c
> Cmos.h
> - FeatureControl.c
> Fv.c
> MemDetect.c
> Platform.c
> @@ -62,10 +62,7 @@ [LibraryClasses]
> PciLib
> ResourcePublicationLib
> PeiServicesLib
> - PeiServicesTablePointerLib
> PeimEntryPoint
> - QemuFwCfgLib
> - QemuFwCfgS3Lib
> MtrrLib
> MemEncryptSevLib
> PcdLib
> @@ -75,13 +72,8 @@ [Pcd]
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> - gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
> - gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
> - gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
> - gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
> - gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
> gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase
> gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize
> @@ -89,31 +81,19 @@ [Pcd]
> gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size
> gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base
> gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size
> - gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
> gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
> - gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
> - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
> gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
> gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
> gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
> - gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
> - gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
> - gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
> gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
> gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
>
> [FixedPcd]
> gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
>
> -[FeaturePcd]
> - gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> -
> [Ppis]
> gEfiPeiMasterBootModePpiGuid
> gEfiPeiMpServicesPpiGuid
> diff --git a/OvmfPkg/PlatformPei/Cmos.h b/OvmfPkg/XenPlatformPei/Cmos.h
> similarity index 92%
> copy from OvmfPkg/PlatformPei/Cmos.h
> copy to OvmfPkg/XenPlatformPei/Cmos.h
> index 949f884c2c..defe677122 100644
> --- a/OvmfPkg/PlatformPei/Cmos.h
> +++ b/OvmfPkg/XenPlatformPei/Cmos.h
> @@ -2,6 +2,8 @@
> PC/AT CMOS access routines
>
> Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> diff --git a/OvmfPkg/PlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
> similarity index 88%
> copy from OvmfPkg/PlatformPei/Platform.h
> copy to OvmfPkg/XenPlatformPei/Platform.h
> index b12a5c1f5f..6ccd5eb66c 100644
> --- a/OvmfPkg/PlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -2,6 +2,8 @@
> Platform PEI module include file.
>
> Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> @@ -78,11 +80,6 @@ PeiFvInitialization (
> VOID
> );
>
> -VOID
> -InstallFeatureControlCallback (
> - VOID
> - );
> -
> VOID
> InstallClearCacheCallback (
> VOID
> @@ -103,8 +100,6 @@ AmdSevInitialize (
> VOID
> );
>
> -extern BOOLEAN mXen;
> -
> VOID
> XenPublishRamRegions (
> VOID
> @@ -112,12 +107,8 @@ XenPublishRamRegions (
>
> extern EFI_BOOT_MODE mBootMode;
>
> -extern BOOLEAN mS3Supported;
> -
> extern UINT8 mPhysMemAddressWidth;
>
> -extern UINT32 mMaxCpuCount;
> -
> extern UINT16 mHostBridgeDevId;
>
> #endif // _PLATFORM_PEI_H_INCLUDED_
> diff --git a/OvmfPkg/PlatformPei/Xen.h b/OvmfPkg/XenPlatformPei/Xen.h
> similarity index 100%
> copy from OvmfPkg/PlatformPei/Xen.h
> copy to OvmfPkg/XenPlatformPei/Xen.h
> diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/XenPlatformPei/AmdSev.c
> similarity index 61%
> copy from OvmfPkg/PlatformPei/AmdSev.c
> copy to OvmfPkg/XenPlatformPei/AmdSev.c
> index 2e14eaf8c3..1a1f46291f 100644
> --- a/OvmfPkg/PlatformPei/AmdSev.c
> +++ b/OvmfPkg/XenPlatformPei/AmdSev.c
> @@ -2,6 +2,7 @@
> Initialize Secure Encrypted Virtualization (SEV) support
>
> Copyright (c) 2017, Advanced Micro Devices. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
>
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> @@ -16,7 +17,6 @@
> // The package level header files this module uses
> //
> #include <Library/DebugLib.h>
> -#include <Library/HobLib.h>
> #include <Library/MemEncryptSevLib.h>
> #include <Library/PcdLib.h>
> #include <PiPei.h>
> @@ -67,32 +67,4 @@ AmdSevInitialize (
> //
> PcdStatus = PcdSet32S (PcdOptionRomImageVerificationPolicy, 0x4);
> ASSERT_RETURN_ERROR (PcdStatus);
> -
> - //
> - // When SMM is required, cover the pages containing the initial SMRAM Save
> - // State Map with a memory allocation HOB:
> - //
> - // There's going to be a time interval between our decrypting those pages for
> - // SMBASE relocation and re-encrypting the same pages after SMBASE
> - // relocation. We shall ensure that the DXE phase stay away from those pages
> - // until after re-encryption, in order to prevent an information leak to the
> - // hypervisor.
> - //
> - if (FeaturePcdGet (PcdSmmSmramRequire) && (mBootMode != BOOT_ON_S3_RESUME)) {
> - RETURN_STATUS LocateMapStatus;
> - UINTN MapPagesBase;
> - UINTN MapPagesCount;
> -
> - LocateMapStatus = MemEncryptSevLocateInitialSmramSaveStateMapPages (
> - &MapPagesBase,
> - &MapPagesCount
> - );
> - ASSERT_RETURN_ERROR (LocateMapStatus);
> -
> - BuildMemoryAllocationHob (
> - MapPagesBase, // BaseAddress
> - EFI_PAGES_TO_SIZE (MapPagesCount), // Length
> - EfiBootServicesData // MemoryType
> - );
> - }
> }
> diff --git a/OvmfPkg/PlatformPei/ClearCache.c b/OvmfPkg/XenPlatformPei/ClearCache.c
> similarity index 95%
> copy from OvmfPkg/PlatformPei/ClearCache.c
> copy to OvmfPkg/XenPlatformPei/ClearCache.c
> index 7d15fd925c..78e22124e3 100644
> --- a/OvmfPkg/PlatformPei/ClearCache.c
> +++ b/OvmfPkg/XenPlatformPei/ClearCache.c
> @@ -6,6 +6,7 @@
> sake.
>
> Copyright (C) 2018, Red Hat, Inc.
> + Copyright (c) 2019, Citrix Systems, Inc.
>
> This program and the accompanying materials are licensed and made available
> under the terms and conditions of the BSD License which accompanies this
> diff --git a/OvmfPkg/PlatformPei/Cmos.c b/OvmfPkg/XenPlatformPei/Cmos.c
> similarity index 92%
> copy from OvmfPkg/PlatformPei/Cmos.c
> copy to OvmfPkg/XenPlatformPei/Cmos.c
> index 48ed2cb8f4..174ec773ec 100644
> --- a/OvmfPkg/PlatformPei/Cmos.c
> +++ b/OvmfPkg/XenPlatformPei/Cmos.c
> @@ -2,6 +2,8 @@
> PC/AT CMOS access routines
>
> Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> diff --git a/OvmfPkg/PlatformPei/Fv.c b/OvmfPkg/XenPlatformPei/Fv.c
> similarity index 72%
> copy from OvmfPkg/PlatformPei/Fv.c
> copy to OvmfPkg/XenPlatformPei/Fv.c
> index 248c585085..388e8768bf 100644
> --- a/OvmfPkg/PlatformPei/Fv.c
> +++ b/OvmfPkg/XenPlatformPei/Fv.c
> @@ -2,6 +2,8 @@
> Build FV related hobs for platform.
>
> Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> @@ -32,8 +34,6 @@ PeiFvInitialization (
> VOID
> )
> {
> - BOOLEAN SecureS3Needed;
> -
> DEBUG ((EFI_D_INFO, "Platform PEI Firmware Volume Initialization\n"));
>
> //
> @@ -44,7 +44,7 @@ PeiFvInitialization (
> BuildMemoryAllocationHob (
> PcdGet32 (PcdOvmfPeiMemFvBase),
> PcdGet32 (PcdOvmfPeiMemFvSize),
> - mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
> + EfiBootServicesData
> );
>
> //
> @@ -52,8 +52,6 @@ PeiFvInitialization (
> //
> BuildFvHob (PcdGet32 (PcdOvmfDxeMemFvBase), PcdGet32 (PcdOvmfDxeMemFvSize));
>
> - SecureS3Needed = mS3Supported && FeaturePcdGet (PcdSmmSmramRequire);
> -
> //
> // Create a memory allocation HOB for the DXE FV.
> //
> @@ -65,25 +63,9 @@ PeiFvInitialization (
> BuildMemoryAllocationHob (
> PcdGet32 (PcdOvmfDxeMemFvBase),
> PcdGet32 (PcdOvmfDxeMemFvSize),
> - SecureS3Needed ? EfiACPIMemoryNVS : EfiBootServicesData
> + EfiBootServicesData
> );
>
> - //
> - // Additionally, said decompression will use temporary memory above the end
> - // of DXEFV, so let's keep away the OS from there too.
> - //
> - if (SecureS3Needed) {
> - UINT32 DxeMemFvEnd;
> -
> - DxeMemFvEnd = PcdGet32 (PcdOvmfDxeMemFvBase) +
> - PcdGet32 (PcdOvmfDxeMemFvSize);
> - BuildMemoryAllocationHob (
> - DxeMemFvEnd,
> - PcdGet32 (PcdOvmfDecompressionScratchEnd) - DxeMemFvEnd,
> - EfiACPIMemoryNVS
> - );
> - }
> -
> //
> // Let PEI know about the DXE FV so it can find the DXE Core
> //
> diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c b/OvmfPkg/XenPlatformPei/MemDetect.c
> new file mode 100644
> index 0000000000..db3d387d1c
> --- /dev/null
> +++ b/OvmfPkg/XenPlatformPei/MemDetect.c
> @@ -0,0 +1,427 @@
> +/**@file
> + Memory Detection for Virtual Machines.
> +
> + Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> + This program and the accompanying materials
> + are licensed and made available under the terms and conditions of the BSD License
> + which accompanies this distribution. The full text of the license may be found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +Module Name:
> +
> + MemDetect.c
> +
> +**/
> +
> +//
> +// The package level header files this module uses
> +//
> +#include <IndustryStandard/Q35MchIch9.h>
> +#include <PiPei.h>
> +
> +//
> +// The Library classes this module consumes
> +//
> +#include <Library/BaseLib.h>
> +#include <Library/BaseMemoryLib.h>
> +#include <Library/DebugLib.h>
> +#include <Library/HobLib.h>
> +#include <Library/IoLib.h>
> +#include <Library/PcdLib.h>
> +#include <Library/PciLib.h>
> +#include <Library/PeimEntryPoint.h>
> +#include <Library/ResourcePublicationLib.h>
> +
> +#include "Platform.h"
> +#include "Cmos.h"
> +
> +UINT8 mPhysMemAddressWidth;
> +
> +STATIC UINT32 mS3AcpiReservedMemoryBase;
> +STATIC UINT32 mS3AcpiReservedMemorySize;
> +
> +STATIC UINT16 mQ35TsegMbytes;
> +
> +VOID
> +Q35TsegMbytesInitialization (
> + VOID
> + )
> +{
> + UINT16 ExtendedTsegMbytes;
> + RETURN_STATUS PcdStatus;
> +
> + if (mHostBridgeDevId != INTEL_Q35_MCH_DEVICE_ID) {
> + DEBUG ((
> + DEBUG_ERROR,
> + "%a: no TSEG (SMRAM) on host bridge DID=0x%04x; "
> + "only DID=0x%04x (Q35) is supported\n",
> + __FUNCTION__,
> + mHostBridgeDevId,
> + INTEL_Q35_MCH_DEVICE_ID
> + ));
> + ASSERT (FALSE);
> + CpuDeadLoop ();
> + }
> +
> + //
> + // Check if QEMU offers an extended TSEG.
> + //
> + // This can be seen from writing MCH_EXT_TSEG_MB_QUERY to the MCH_EXT_TSEG_MB
> + // register, and reading back the register.
> + //
> + // On a QEMU machine type that does not offer an extended TSEG, the initial
> + // write overwrites whatever value a malicious guest OS may have placed in
> + // the (unimplemented) register, before entering S3 or rebooting.
> + // Subsequently, the read returns MCH_EXT_TSEG_MB_QUERY unchanged.
> + //
> + // On a QEMU machine type that offers an extended TSEG, the initial write
> + // triggers an update to the register. Subsequently, the value read back
> + // (which is guaranteed to differ from MCH_EXT_TSEG_MB_QUERY) tells us the
> + // number of megabytes.
> + //
> + PciWrite16 (DRAMC_REGISTER_Q35 (MCH_EXT_TSEG_MB), MCH_EXT_TSEG_MB_QUERY);
> + ExtendedTsegMbytes = PciRead16 (DRAMC_REGISTER_Q35 (MCH_EXT_TSEG_MB));
> + if (ExtendedTsegMbytes == MCH_EXT_TSEG_MB_QUERY) {
> + mQ35TsegMbytes = PcdGet16 (PcdQ35TsegMbytes);
> + return;
> + }
> +
> + DEBUG ((
> + DEBUG_INFO,
> + "%a: QEMU offers an extended TSEG (%d MB)\n",
> + __FUNCTION__,
> + ExtendedTsegMbytes
> + ));
> + PcdStatus = PcdSet16S (PcdQ35TsegMbytes, ExtendedTsegMbytes);
> + ASSERT_RETURN_ERROR (PcdStatus);
> + mQ35TsegMbytes = ExtendedTsegMbytes;
> +}
> +
> +
> +UINT32
> +GetSystemMemorySizeBelow4gb (
> + VOID
> + )
> +{
> + UINT8 Cmos0x34;
> + UINT8 Cmos0x35;
> +
> + //
> + // CMOS 0x34/0x35 specifies the system memory above 16 MB.
> + // * CMOS(0x35) is the high byte
> + // * CMOS(0x34) is the low byte
> + // * The size is specified in 64kb chunks
> + // * Since this is memory above 16MB, the 16MB must be added
> + // into the calculation to get the total memory size.
> + //
> +
> + Cmos0x34 = (UINT8) CmosRead8 (0x34);
> + Cmos0x35 = (UINT8) CmosRead8 (0x35);
> +
> + return (UINT32) (((UINTN)((Cmos0x35 << 8) + Cmos0x34) << 16) + SIZE_16MB);
> +}
> +
> +
> +STATIC
> +UINT64
> +GetSystemMemorySizeAbove4gb (
> + )
> +{
> + UINT32 Size;
> + UINTN CmosIndex;
> +
> + //
> + // CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
> + // * CMOS(0x5d) is the most significant size byte
> + // * CMOS(0x5c) is the middle size byte
> + // * CMOS(0x5b) is the least significant size byte
> + // * The size is specified in 64kb chunks
> + //
> +
> + Size = 0;
> + for (CmosIndex = 0x5d; CmosIndex >= 0x5b; CmosIndex--) {
> + Size = (UINT32) (Size << 8) + (UINT32) CmosRead8 (CmosIndex);
> + }
> +
> + return LShiftU64 (Size, 16);
> +}
> +
> +
> +/**
> + Return the highest address that DXE could possibly use, plus one.
> +**/
> +STATIC
> +UINT64
> +GetFirstNonAddress (
> + VOID
> + )
> +{
> + UINT64 FirstNonAddress;
> + UINT64 Pci64Base, Pci64Size;
> + RETURN_STATUS PcdStatus;
> +
> + FirstNonAddress = BASE_4GB + GetSystemMemorySizeAbove4gb ();
> +
> + //
> + // If DXE is 32-bit, then we're done; PciBusDxe will degrade 64-bit MMIO
> + // resources to 32-bit anyway. See DegradeResource() in
> + // "PciResourceSupport.c".
> + //
> +#ifdef MDE_CPU_IA32
> + if (!FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
> + return FirstNonAddress;
> + }
> +#endif
> +
> + //
> + // 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);
> +
> + if (Pci64Size == 0) {
> + if (mBootMode != BOOT_ON_S3_RESUME) {
> + DEBUG ((EFI_D_INFO, "%a: disabling 64-bit PCI host aperture\n",
> + __FUNCTION__));
> + PcdStatus = PcdSet64S (PcdPciMmio64Size, 0);
> + ASSERT_RETURN_ERROR (PcdStatus);
> + }
> +
> + //
> + // There's nothing more to do; the amount of memory above 4GB fully
> + // determines the highest address plus one. The memory hotplug area (see
> + // below) plays no role for the firmware in this case.
> + //
> + return FirstNonAddress;
> + }
> +
> + //
> + // SeaBIOS aligns both boundaries of the 64-bit PCI host aperture to 1GB, so
> + // that the host can map it with 1GB hugepages. Follow suit.
> + //
> + Pci64Base = ALIGN_VALUE (FirstNonAddress, (UINT64)SIZE_1GB);
> + Pci64Size = ALIGN_VALUE (Pci64Size, (UINT64)SIZE_1GB);
> +
> + //
> + // The 64-bit PCI host aperture should also be "naturally" aligned. The
> + // alignment is determined by rounding the size of the aperture down to the
> + // next smaller or equal power of two. That is, align the aperture by the
> + // largest BAR size that can fit into it.
> + //
> + Pci64Base = ALIGN_VALUE (Pci64Base, GetPowerOfTwo64 (Pci64Size));
> +
> + if (mBootMode != BOOT_ON_S3_RESUME) {
> + //
> + // The core PciHostBridgeDxe driver will automatically add this range to
> + // the GCD memory space map through our PciHostBridgeLib instance; here we
> + // only need to set the PCDs.
> + //
> + PcdStatus = PcdSet64S (PcdPciMmio64Base, Pci64Base);
> + ASSERT_RETURN_ERROR (PcdStatus);
> + PcdStatus = PcdSet64S (PcdPciMmio64Size, Pci64Size);
> + ASSERT_RETURN_ERROR (PcdStatus);
> +
> + DEBUG ((EFI_D_INFO, "%a: Pci64Base=0x%Lx Pci64Size=0x%Lx\n",
> + __FUNCTION__, Pci64Base, Pci64Size));
> + }
> +
> + //
> + // The useful address space ends with the 64-bit PCI host aperture.
> + //
> + FirstNonAddress = Pci64Base + Pci64Size;
> + return FirstNonAddress;
> +}
> +
> +
> +/**
> + Initialize the mPhysMemAddressWidth variable, based on guest RAM size.
> +**/
> +VOID
> +AddressWidthInitialization (
> + VOID
> + )
> +{
> + UINT64 FirstNonAddress;
> +
> + //
> + // As guest-physical memory size grows, the permanent PEI RAM requirements
> + // are dominated by the identity-mapping page tables built by the DXE IPL.
> + // The DXL IPL keys off of the physical address bits advertized in the CPU
> + // HOB. To conserve memory, we calculate the minimum address width here.
> + //
> + FirstNonAddress = GetFirstNonAddress ();
> + mPhysMemAddressWidth = (UINT8)HighBitSet64 (FirstNonAddress);
> +
> + //
> + // If FirstNonAddress is not an integral power of two, then we need an
> + // additional bit.
> + //
> + if ((FirstNonAddress & (FirstNonAddress - 1)) != 0) {
> + ++mPhysMemAddressWidth;
> + }
> +
> + //
> + // The minimum address width is 36 (covers up to and excluding 64 GB, which
> + // is the maximum for Ia32 + PAE). The theoretical architecture maximum for
> + // X64 long mode is 52 bits, but the DXE IPL clamps that down to 48 bits. We
> + // can simply assert that here, since 48 bits are good enough for 256 TB.
> + //
> + if (mPhysMemAddressWidth <= 36) {
> + mPhysMemAddressWidth = 36;
> + }
> + ASSERT (mPhysMemAddressWidth <= 48);
> +}
> +
> +
> +/**
> + Calculate the cap for the permanent PEI memory.
> +**/
> +STATIC
> +UINT32
> +GetPeiMemoryCap (
> + VOID
> + )
> +{
> + BOOLEAN Page1GSupport;
> + UINT32 RegEax;
> + UINT32 RegEdx;
> + UINT32 Pml4Entries;
> + UINT32 PdpEntries;
> + UINTN TotalPages;
> +
> + //
> + // If DXE is 32-bit, then just return the traditional 64 MB cap.
> + //
> +#ifdef MDE_CPU_IA32
> + if (!FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
> + return SIZE_64MB;
> + }
> +#endif
> +
> + //
> + // Dependent on physical address width, PEI memory allocations can be
> + // dominated by the page tables built for 64-bit DXE. So we key the cap off
> + // of those. The code below is based on CreateIdentityMappingPageTables() in
> + // "MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c".
> + //
> + Page1GSupport = FALSE;
> + if (PcdGetBool (PcdUse1GPageTable)) {
> + AsmCpuid (0x80000000, &RegEax, NULL, NULL, NULL);
> + if (RegEax >= 0x80000001) {
> + AsmCpuid (0x80000001, NULL, NULL, NULL, &RegEdx);
> + if ((RegEdx & BIT26) != 0) {
> + Page1GSupport = TRUE;
> + }
> + }
> + }
> +
> + if (mPhysMemAddressWidth <= 39) {
> + Pml4Entries = 1;
> + PdpEntries = 1 << (mPhysMemAddressWidth - 30);
> + ASSERT (PdpEntries <= 0x200);
> + } else {
> + Pml4Entries = 1 << (mPhysMemAddressWidth - 39);
> + ASSERT (Pml4Entries <= 0x200);
> + PdpEntries = 512;
> + }
> +
> + TotalPages = Page1GSupport ? Pml4Entries + 1 :
> + (PdpEntries + 1) * Pml4Entries + 1;
> + ASSERT (TotalPages <= 0x40201);
> +
> + //
> + // Add 64 MB for miscellaneous allocations. Note that for
> + // mPhysMemAddressWidth values close to 36, the cap will actually be
> + // dominated by this increment.
> + //
> + return (UINT32)(EFI_PAGES_TO_SIZE (TotalPages) + SIZE_64MB);
> +}
> +
> +
> +/**
> + Publish PEI core memory
> +
> + @return EFI_SUCCESS The PEIM initialized successfully.
> +
> +**/
> +EFI_STATUS
> +PublishPeiMemory (
> + VOID
> + )
> +{
> + EFI_STATUS Status;
> + EFI_PHYSICAL_ADDRESS MemoryBase;
> + UINT64 MemorySize;
> + UINT32 LowerMemorySize;
> + UINT32 PeiMemoryCap;
> +
> + LowerMemorySize = GetSystemMemorySizeBelow4gb ();
> +
> + if (mBootMode == BOOT_ON_S3_RESUME) {
> + MemoryBase = mS3AcpiReservedMemoryBase;
> + MemorySize = mS3AcpiReservedMemorySize;
> + } else {
> + PeiMemoryCap = GetPeiMemoryCap ();
> + DEBUG ((EFI_D_INFO, "%a: mPhysMemAddressWidth=%d PeiMemoryCap=%u KB\n",
> + __FUNCTION__, mPhysMemAddressWidth, PeiMemoryCap >> 10));
> +
> + //
> + // Determine the range of memory to use during PEI
> + //
> + MemoryBase =
> + PcdGet32 (PcdOvmfDxeMemFvBase) + PcdGet32 (PcdOvmfDxeMemFvSize);
> + MemorySize = LowerMemorySize - MemoryBase;
> + if (MemorySize > PeiMemoryCap) {
> + MemoryBase = LowerMemorySize - PeiMemoryCap;
> + MemorySize = PeiMemoryCap;
> + }
> + }
> +
> + //
> + // Publish this memory to the PEI Core
> + //
> + Status = PublishSystemMemory(MemoryBase, MemorySize);
> + ASSERT_EFI_ERROR (Status);
> +
> + return Status;
> +}
> +
> +
> +/**
> + Publish system RAM and reserve memory regions
> +
> +**/
> +VOID
> +InitializeRamRegions (
> + VOID
> + )
> +{
> + XenPublishRamRegions ();
> +
> + if (mBootMode != BOOT_ON_S3_RESUME) {
> + //
> + // Reserve the lock box storage area
> + //
> + // Since this memory range will be used on S3 resume, it must be
> + // reserved as ACPI NVS.
> + //
> + // If S3 is unsupported, then various drivers might still write to the
> + // LockBox area. We ought to prevent DXE from serving allocation requests
> + // such that they would overlap the LockBox storage.
> + //
> + ZeroMem (
> + (VOID*)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
> + (UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize)
> + );
> + BuildMemoryAllocationHob (
> + (EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
> + (UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize),
> + EfiBootServicesData
> + );
> + }
> +}
> diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
> similarity index 56%
> copy from OvmfPkg/PlatformPei/Platform.c
> copy to OvmfPkg/XenPlatformPei/Platform.c
> index 22139a64cb..2d567a4760 100644
> --- a/OvmfPkg/PlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -3,6 +3,7 @@
>
> Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
> Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
> + Copyright (c) 2019, Citrix Systems, Inc.
>
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> @@ -31,8 +32,6 @@
> #include <Library/PciLib.h>
> #include <Library/PeimEntryPoint.h>
> #include <Library/PeiServicesLib.h>
> -#include <Library/QemuFwCfgLib.h>
> -#include <Library/QemuFwCfgS3Lib.h>
> #include <Library/ResourcePublicationLib.h>
> #include <Guid/MemoryTypeInformation.h>
> #include <Ppi/MasterBootMode.h>
> @@ -67,9 +66,6 @@ UINT16 mHostBridgeDevId;
>
> EFI_BOOT_MODE mBootMode = BOOT_WITH_FULL_CONFIGURATION;
>
> -BOOLEAN mS3Supported = FALSE;
> -
> -UINT32 mMaxCpuCount;
>
> VOID
> AddIoMemoryBaseSizeHob (
> @@ -179,89 +175,6 @@ MemMapInitialization (
> //
> AddIoMemoryRangeHob (0x0A0000, BASE_1MB);
>
> - if (!mXen) {
> - UINT32 TopOfLowRam;
> - UINT64 PciExBarBase;
> - UINT32 PciBase;
> - UINT32 PciSize;
> -
> - TopOfLowRam = GetSystemMemorySizeBelow4gb ();
> - PciExBarBase = 0;
> - if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
> - //
> - // The MMCONFIG area is expected to fall between the top of low RAM and
> - // the base of the 32-bit PCI host aperture.
> - //
> - PciExBarBase = FixedPcdGet64 (PcdPciExpressBaseAddress);
> - ASSERT (TopOfLowRam <= PciExBarBase);
> - ASSERT (PciExBarBase <= MAX_UINT32 - SIZE_256MB);
> - PciBase = (UINT32)(PciExBarBase + SIZE_256MB);
> - } else {
> - PciBase = (TopOfLowRam < BASE_2GB) ? BASE_2GB : TopOfLowRam;
> - }
> -
> - //
> - // address purpose size
> - // ------------ -------- -------------------------
> - // max(top, 2g) PCI MMIO 0xFC000000 - max(top, 2g)
> - // 0xFC000000 gap 44 MB
> - // 0xFEC00000 IO-APIC 4 KB
> - // 0xFEC01000 gap 1020 KB
> - // 0xFED00000 HPET 1 KB
> - // 0xFED00400 gap 111 KB
> - // 0xFED1C000 gap (PIIX4) / RCRB (ICH9) 16 KB
> - // 0xFED20000 gap 896 KB
> - // 0xFEE00000 LAPIC 1 MB
> - //
> - PciSize = 0xFC000000 - PciBase;
> - AddIoMemoryBaseSizeHob (PciBase, PciSize);
> - PcdStatus = PcdSet64S (PcdPciMmio32Base, PciBase);
> - ASSERT_RETURN_ERROR (PcdStatus);
> - PcdStatus = PcdSet64S (PcdPciMmio32Size, PciSize);
> - ASSERT_RETURN_ERROR (PcdStatus);
> -
> - AddIoMemoryBaseSizeHob (0xFEC00000, SIZE_4KB);
> - AddIoMemoryBaseSizeHob (0xFED00000, SIZE_1KB);
> - if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
> - AddIoMemoryBaseSizeHob (ICH9_ROOT_COMPLEX_BASE, SIZE_16KB);
> - //
> - // Note: there should be an
> - //
> - // AddIoMemoryBaseSizeHob (PciExBarBase, SIZE_256MB);
> - //
> - // call below, just like the one above for RCBA. However, Linux insists
> - // that the MMCONFIG area be marked in the E820 or UEFI memory map as
> - // "reserved memory" -- Linux does not content itself with a simple gap
> - // in the memory map wherever the MCFG ACPI table points to.
> - //
> - // This appears to be a safety measure. The PCI Firmware Specification
> - // (rev 3.1) says in 4.1.2. "MCFG Table Description": "The resources can
> - // *optionally* be returned in [...] EFIGetMemoryMap as reserved memory
> - // [...]". (Emphasis added here.)
> - //
> - // Normally we add memory resource descriptor HOBs in
> - // QemuInitializeRam(), and pre-allocate from those with memory
> - // allocation HOBs in InitializeRamRegions(). However, the MMCONFIG area
> - // is most definitely not RAM; so, as an exception, cover it with
> - // uncacheable reserved memory right here.
> - //
> - AddReservedMemoryBaseSizeHob (PciExBarBase, SIZE_256MB, FALSE);
> - BuildMemoryAllocationHob (PciExBarBase, SIZE_256MB,
> - EfiReservedMemoryType);
> - }
> - AddIoMemoryBaseSizeHob (PcdGet32(PcdCpuLocalApicBaseAddress), SIZE_1MB);
> -
> - //
> - // On Q35, the IO Port space is available for PCI resource allocations from
> - // 0x6000 up.
> - //
> - if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
> - PciIoBase = 0x6000;
> - PciIoSize = 0xA000;
> - ASSERT ((ICH9_PMBASE_VALUE & 0xF000) < PciIoBase);
> - }
> - }
> -
> //
> // Add PCI IO Port space available for PCI resource allocations.
> //
> @@ -278,71 +191,6 @@ MemMapInitialization (
> ASSERT_RETURN_ERROR (PcdStatus);
> }
>
> -EFI_STATUS
> -GetNamedFwCfgBoolean (
> - IN CHAR8 *FwCfgFileName,
> - OUT BOOLEAN *Setting
> - )
> -{
> - EFI_STATUS Status;
> - FIRMWARE_CONFIG_ITEM FwCfgItem;
> - UINTN FwCfgSize;
> - UINT8 Value[3];
> -
> - Status = QemuFwCfgFindFile (FwCfgFileName, &FwCfgItem, &FwCfgSize);
> - if (EFI_ERROR (Status)) {
> - return Status;
> - }
> - if (FwCfgSize > sizeof Value) {
> - return EFI_BAD_BUFFER_SIZE;
> - }
> - QemuFwCfgSelectItem (FwCfgItem);
> - QemuFwCfgReadBytes (FwCfgSize, Value);
> -
> - if ((FwCfgSize == 1) ||
> - (FwCfgSize == 2 && Value[1] == '\n') ||
> - (FwCfgSize == 3 && Value[1] == '\r' && Value[2] == '\n')) {
> - switch (Value[0]) {
> - case '0':
> - case 'n':
> - case 'N':
> - *Setting = FALSE;
> - return EFI_SUCCESS;
> -
> - case '1':
> - case 'y':
> - case 'Y':
> - *Setting = TRUE;
> - return EFI_SUCCESS;
> -
> - default:
> - break;
> - }
> - }
> - return EFI_PROTOCOL_ERROR;
> -}
> -
> -#define UPDATE_BOOLEAN_PCD_FROM_FW_CFG(TokenName) \
> - do { \
> - BOOLEAN Setting; \
> - RETURN_STATUS PcdStatus; \
> - \
> - if (!EFI_ERROR (GetNamedFwCfgBoolean ( \
> - "opt/ovmf/" #TokenName, &Setting))) { \
> - PcdStatus = PcdSetBoolS (TokenName, Setting); \
> - ASSERT_RETURN_ERROR (PcdStatus); \
> - } \
> - } while (0)
> -
> -VOID
> -NoexecDxeInitialization (
> - VOID
> - )
> -{
> - UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdPropertiesTableEnable);
> - UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdSetNxForStack);
> -}
> -
> VOID
> PciExBarInitialization (
> VOID
> @@ -547,67 +395,6 @@ DebugDumpCmos (
> }
>
>
> -VOID
> -S3Verification (
> - VOID
> - )
> -{
> -#if defined (MDE_CPU_X64)
> - if (FeaturePcdGet (PcdSmmSmramRequire) && mS3Supported) {
> - DEBUG ((EFI_D_ERROR,
> - "%a: S3Resume2Pei doesn't support X64 PEI + SMM yet.\n", __FUNCTION__));
> - DEBUG ((EFI_D_ERROR,
> - "%a: Please disable S3 on the QEMU command line (see the README),\n",
> - __FUNCTION__));
> - DEBUG ((EFI_D_ERROR,
> - "%a: or build OVMF with \"OvmfPkgIa32X64.dsc\".\n", __FUNCTION__));
> - ASSERT (FALSE);
> - CpuDeadLoop ();
> - }
> -#endif
> -}
> -
> -
> -/**
> - Fetch the number of boot CPUs from QEMU and expose it to UefiCpuPkg modules.
> - Set the mMaxCpuCount variable.
> -**/
> -VOID
> -MaxCpuCountInitialization (
> - VOID
> - )
> -{
> - UINT16 ProcessorCount;
> - RETURN_STATUS PcdStatus;
> -
> - QemuFwCfgSelectItem (QemuFwCfgItemSmpCpuCount);
> - ProcessorCount = QemuFwCfgRead16 ();
> - //
> - // If the fw_cfg key or fw_cfg entirely is unavailable, load mMaxCpuCount
> - // from the PCD default. No change to PCDs.
> - //
> - if (ProcessorCount == 0) {
> - mMaxCpuCount = PcdGet32 (PcdCpuMaxLogicalProcessorNumber);
> - return;
> - }
> - //
> - // Otherwise, set mMaxCpuCount to the value reported by QEMU.
> - //
> - mMaxCpuCount = ProcessorCount;
> - //
> - // Additionally, tell UefiCpuPkg modules (a) the exact number of VCPUs, (b)
> - // to wait, in the initial AP bringup, exactly as long as it takes for all of
> - // the APs to report in. For this, we set the longest representable timeout
> - // (approx. 71 minutes).
> - //
> - PcdStatus = PcdSet32S (PcdCpuMaxLogicalProcessorNumber, ProcessorCount);
> - ASSERT_RETURN_ERROR (PcdStatus);
> - PcdStatus = PcdSet32S (PcdCpuApInitTimeOutInMicroSeconds, MAX_UINT32);
> - ASSERT_RETURN_ERROR (PcdStatus);
> - DEBUG ((DEBUG_INFO, "%a: QEMU reports %d processor(s)\n", __FUNCTION__,
> - ProcessorCount));
> -}
> -
>
> /**
> Perform Platform PEI initialization.
> @@ -620,62 +407,43 @@ MaxCpuCountInitialization (
> **/
> EFI_STATUS
> EFIAPI
> -InitializePlatform (
> +InitializeXenPlatform (
> IN EFI_PEI_FILE_HANDLE FileHandle,
> IN CONST EFI_PEI_SERVICES **PeiServices
> )
> {
> - EFI_STATUS Status;
> -
> DEBUG ((DEBUG_INFO, "Platform PEIM Loaded\n"));
>
> DebugDumpCmos ();
>
> - XenDetect ();
> -
> - if (QemuFwCfgS3Enabled ()) {
> - DEBUG ((EFI_D_INFO, "S3 support was detected on QEMU\n"));
> - mS3Supported = TRUE;
> - Status = PcdSetBoolS (PcdAcpiS3Enable, TRUE);
> - ASSERT_EFI_ERROR (Status);
> + if (!XenDetect ()) {
> + DEBUG ((EFI_D_ERROR, "ERROR: Xen isn't detected\n"));
> + CpuDeadLoop ();
> }
(2) This is brand new code.
- In new code, we should use DEBUG_xxx, not EFI_D_xxx.
- Please insert an "ASSERT (FALSE);" before CpuDeadLoop (). The current
code is not wrong, but assertion failures can be configured to have a
disposition different from an internal CpuDeadLoop(), and
ASSERT(FALSE) + CpuDeadLoop() is both safe and preserves this
configurability. It's just an edk2 pattern that was recommended to me
earlier and I've followed it too since.
With (2) updated (and (1) is up to you):
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
I'll try to continue reviewing the series tomorrow.
Thanks,
Laszlo
>
> - S3Verification ();
> BootModeInitialization ();
> AddressWidthInitialization ();
> - MaxCpuCountInitialization ();
>
> //
> // Query Host Bridge DID
> //
> mHostBridgeDevId = PciRead16 (OVMF_HOSTBRIDGE_DID);
>
> - if (FeaturePcdGet (PcdSmmSmramRequire)) {
> - Q35TsegMbytesInitialization ();
> - }
> -
> PublishPeiMemory ();
>
> InitializeRamRegions ();
>
> - if (mXen) {
> - DEBUG ((EFI_D_INFO, "Xen was detected\n"));
> - InitializeXen ();
> - }
> + InitializeXen ();
>
> if (mBootMode != BOOT_ON_S3_RESUME) {
> - if (!FeaturePcdGet (PcdSmmSmramRequire)) {
> - ReserveEmuVariableNvStore ();
> - }
> + ReserveEmuVariableNvStore ();
> PeiFvInitialization ();
> MemMapInitialization ();
> - NoexecDxeInitialization ();
> }
>
> InstallClearCacheCallback ();
> AmdSevInitialize ();
> MiscInitialization ();
> - InstallFeatureControlCallback ();
>
> return EFI_SUCCESS;
> }
> diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> similarity index 94%
> copy from OvmfPkg/PlatformPei/Xen.c
> copy to OvmfPkg/XenPlatformPei/Xen.c
> index ab38f97a67..7c82e5b69b 100644
> --- a/OvmfPkg/PlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -3,6 +3,7 @@
>
> Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
> Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
> + Copyright (c) 2019, Citrix Systems, Inc.
>
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> @@ -34,8 +35,6 @@
> #include "Platform.h"
> #include "Xen.h"
>
> -BOOLEAN mXen = FALSE;
> -
> STATIC UINT32 mXenLeaf = 0;
>
> EFI_XEN_INFO mXenInfo;
> @@ -143,7 +142,6 @@ XenDetect (
> (UINT32 *) &Signature[8]);
>
> if (!AsciiStrCmp ((CHAR8 *) Signature, "XenVMMXenVMM")) {
> - mXen = TRUE;
> return TRUE;
> }
> }
> @@ -162,10 +160,6 @@ XenPublishRamRegions (
> UINT32 E820EntriesCount;
> EFI_STATUS Status;
>
> - if (!mXen) {
> - return;
> - }
> -
> DEBUG ((EFI_D_INFO, "Using memory map provided by Xen\n"));
>
> //
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 05/31] OvmfPkg/XenOvmf: Creating an ELF header
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This header replace the embedded variable store.
The ELF header explain to a loader to load the binary at the address
1MB, then jump to the PVH entry point which will be created in a later
patch.
That patch include generate_elf_header.c which can be use to regenerate
the ELF header, but this will be a manual step.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
This "ELF header" might not be the best way, but with it the Xen
toolstack can load OVMF like any other PVH-compatible kernel without
modification. Is there a better way?
The generate_elf_header.c file was used to generate the series of hex
number. It isn't at a right place but I'm not sure where to put this C
file. Maybe in the commit message or maybe it could be forgotten since
I've added all the comments in the .fdf file.
OvmfPkg/XenOvmf.fdf | 82 +++++++++++++++++++-
| 78 +++++++++++++++++++
2 files changed, 157 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 295e30ca3f..20ebacd673 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -21,8 +21,8 @@ [Defines]
!include OvmfPkg.fdf.inc
#
-# Build the variable store and the firmware code as one unified flash device
-# image.
+# This will allow the flash device image to be recognize as an ELF, with first
+# an ELF headers, then the firmware code.
#
[FD.OVMF]
BaseAddress = $(FW_BASE_ADDRESS)
@@ -31,7 +31,83 @@ [FD.OVMF]
BlockSize = $(BLOCK_SIZE)
NumBlocks = $(FW_BLOCKS)
-!include VarStore.fdf.inc
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x00000000|0x0000e000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00000000|0x00040000
+!endif
+#was NV_VARIABLE_STORE
+DATA = {
+ # ELF file header
+ 0x7f, 0x45, 0x4c, 0x46, # e_ident[0..3]: Magic number
+ 0x01, # File class: 32-bit objects
+ 0x01, # Data encoding: 2's complement, little endian
+ 0x01, # File version
+ 0x03, # OS ABI identification: Object uses GNU ELF extensions
+ 0x00, # ABI version
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, # e_ident[EI_PAD...]
+
+ 0x02, 0x00, # e_type = Executable file
+ 0x03, 0x00, # e_machine = Intel 80386
+ 0x01, 0x00, 0x00, 0x00, # e_version
+ 0xd0, 0xff, 0x2f, 0x00, # e_entry: Entry point virtual address
+ 0x34, 0x00, 0x00, 0x00, # e_phoff: Program header table file offset
+ 0x00, 0x00, 0x00, 0x00, # e_shoff: Section header table file offset
+ 0x00, 0x00, 0x00, 0x00, # e_flags: Processor-specific flags
+ 0x34, 0x00, # e_ehsize: ELF header size
+ 0x20, 0x00, # e_phentsize: Program header table entry size
+ 0x01, 0x00, # e_phnum: Program header table entry count
+ 0x00, 0x00, # e_shentsize: Section header table entry size
+ 0x00, 0x00, # e_shnum: Section header table entry count
+ 0xff, 0xff, # e_shstrndx
+
+ # ELF Program segment header
+ 0x01, 0x00, 0x00, 0x00, # p_type = Loadable program segment
+ 0x00, 0x00, 0x00, 0x00, # p_offset
+ 0x00, 0x00, 0x10, 0x00, # p_vaddr: Segment virtual address
+ 0x00, 0x00, 0x10, 0x00, # p_paddr: Segment physical address
+ 0x00, 0x00, 0x20, 0x00, # p_filesz: Segment size in file
+ 0x00, 0x00, 0x20, 0x00, # p_memsz: Segment size in memory
+ 0x07, 0x00, 0x00, 0x00, # p_flags = Segment is executable | writable | readable
+ 0x00, 0x00, 0x00, 0x00 # p_align
+
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x0000e000|0x00001000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00040000|0x00001000
+!endif
+#NV_EVENT_LOG
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x0000f000|0x00001000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00041000|0x00001000
+!endif
+#NV_FTW_WORKING
+DATA = {
+ # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = gEdkiiWorkingBlockSignatureGuid =
+ # { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95 }}
+ 0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
+ 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95,
+ # Crc:UINT32 #WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
+ 0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
+ # WriteQueueSize: UINT64
+ 0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x00010000|0x00010000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00042000|0x00042000
+!endif
+#NV_FTW_SPARE
+
$(VARS_SIZE)|$(FVMAIN_SIZE)
FV = FVMAIN_COMPACT
--git a/generate_elf_header.c b/generate_elf_header.c
new file mode 100644
index 0000000000..5bb87df0d6
--- /dev/null
+++ b/generate_elf_header.c
@@ -0,0 +1,78 @@
+#include "elf.h"
+#include "stdio.h"
+#include "stddef.h"
+
+/*
+ * TODO:
+ * this header will need a XEN_ELFNOTE_PHYS32_ENTRY
+ * right now, it works without, but that might change.
+ */
+
+void print_hdr(void *s, size_t size) {
+ char *c = s;
+
+ while (size--) {
+ printf("0x%02hhx, ", *(c++));
+ }
+}
+int main(void){
+ // FW_SIZE
+ size_t ovmf_blob_size = 0x00200000;
+ // Load OVMF at 1MB when running as PVH guest
+ uint32_t ovmf_base_address = 0x00100000;
+
+ /* ELF file header */
+ Elf32_Ehdr hdr = {
+ .e_ident = ELFMAG,
+ .e_type = ET_EXEC,
+ .e_machine = EM_386,
+ .e_version = EV_CURRENT,
+ // PVH entry point
+ .e_entry = ovmf_base_address + ovmf_blob_size - 0x30,
+ };
+
+ hdr.e_ident[EI_CLASS] = ELFCLASS32;
+ hdr.e_ident[EI_DATA] = ELFDATA2LSB;
+ hdr.e_ident[EI_VERSION] = EV_CURRENT;
+ hdr.e_ident[EI_OSABI] = ELFOSABI_LINUX;
+ hdr.e_flags = R_386_NONE;
+ hdr.e_ehsize = sizeof (hdr);
+ /* about program header */
+ hdr.e_phoff = sizeof (hdr);
+ /* about section header */
+ hdr.e_shentsize = 0;
+ hdr.e_shnum = 0;
+ hdr.e_shstrndx = -1;
+
+ /* program header */
+ Elf32_Phdr phdr = {
+ .p_type = PT_LOAD,
+ .p_offset = 0, // load everything
+ .p_paddr = ovmf_base_address,
+ .p_filesz = ovmf_blob_size,
+ .p_memsz = ovmf_blob_size,
+ .p_flags = PF_X | PF_W | PF_R,
+ .p_align = 0, // is this needed?
+ };
+ phdr.p_vaddr = phdr.p_paddr;
+
+ hdr.e_phnum += 1;
+ hdr.e_phentsize += sizeof (phdr);
+
+ /* section header */
+ Elf32_Shdr shdr = {
+ };
+
+ size_t hdr_size = sizeof(hdr);
+ size_t entry_off = offsetof(typeof(hdr), e_entry);
+ printf("# ELF file header\n");
+ print_hdr(&hdr, entry_off);
+ printf("\n# hdr.e_entry\n");
+ print_hdr(&hdr.e_entry, sizeof(hdr.e_entry));
+ printf("\n# the rest\n");
+ print_hdr(&hdr.e_entry + 1, hdr_size - entry_off - sizeof(hdr.e_entry));
+ printf("\n# Program segment header\n");
+ print_hdr(&phdr, sizeof (phdr));
+
+ return 0;
+}
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 05/31] OvmfPkg/XenOvmf: Creating an ELF header
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This header replace the embedded variable store.
The ELF header explain to a loader to load the binary at the address
1MB, then jump to the PVH entry point which will be created in a later
patch.
That patch include generate_elf_header.c which can be use to regenerate
the ELF header, but this will be a manual step.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
This "ELF header" might not be the best way, but with it the Xen
toolstack can load OVMF like any other PVH-compatible kernel without
modification. Is there a better way?
The generate_elf_header.c file was used to generate the series of hex
number. It isn't at a right place but I'm not sure where to put this C
file. Maybe in the commit message or maybe it could be forgotten since
I've added all the comments in the .fdf file.
OvmfPkg/XenOvmf.fdf | 82 +++++++++++++++++++-
| 78 +++++++++++++++++++
2 files changed, 157 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 295e30ca3f..20ebacd673 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -21,8 +21,8 @@ [Defines]
!include OvmfPkg.fdf.inc
#
-# Build the variable store and the firmware code as one unified flash device
-# image.
+# This will allow the flash device image to be recognize as an ELF, with first
+# an ELF headers, then the firmware code.
#
[FD.OVMF]
BaseAddress = $(FW_BASE_ADDRESS)
@@ -31,7 +31,83 @@ [FD.OVMF]
BlockSize = $(BLOCK_SIZE)
NumBlocks = $(FW_BLOCKS)
-!include VarStore.fdf.inc
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x00000000|0x0000e000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00000000|0x00040000
+!endif
+#was NV_VARIABLE_STORE
+DATA = {
+ # ELF file header
+ 0x7f, 0x45, 0x4c, 0x46, # e_ident[0..3]: Magic number
+ 0x01, # File class: 32-bit objects
+ 0x01, # Data encoding: 2's complement, little endian
+ 0x01, # File version
+ 0x03, # OS ABI identification: Object uses GNU ELF extensions
+ 0x00, # ABI version
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, # e_ident[EI_PAD...]
+
+ 0x02, 0x00, # e_type = Executable file
+ 0x03, 0x00, # e_machine = Intel 80386
+ 0x01, 0x00, 0x00, 0x00, # e_version
+ 0xd0, 0xff, 0x2f, 0x00, # e_entry: Entry point virtual address
+ 0x34, 0x00, 0x00, 0x00, # e_phoff: Program header table file offset
+ 0x00, 0x00, 0x00, 0x00, # e_shoff: Section header table file offset
+ 0x00, 0x00, 0x00, 0x00, # e_flags: Processor-specific flags
+ 0x34, 0x00, # e_ehsize: ELF header size
+ 0x20, 0x00, # e_phentsize: Program header table entry size
+ 0x01, 0x00, # e_phnum: Program header table entry count
+ 0x00, 0x00, # e_shentsize: Section header table entry size
+ 0x00, 0x00, # e_shnum: Section header table entry count
+ 0xff, 0xff, # e_shstrndx
+
+ # ELF Program segment header
+ 0x01, 0x00, 0x00, 0x00, # p_type = Loadable program segment
+ 0x00, 0x00, 0x00, 0x00, # p_offset
+ 0x00, 0x00, 0x10, 0x00, # p_vaddr: Segment virtual address
+ 0x00, 0x00, 0x10, 0x00, # p_paddr: Segment physical address
+ 0x00, 0x00, 0x20, 0x00, # p_filesz: Segment size in file
+ 0x00, 0x00, 0x20, 0x00, # p_memsz: Segment size in memory
+ 0x07, 0x00, 0x00, 0x00, # p_flags = Segment is executable | writable | readable
+ 0x00, 0x00, 0x00, 0x00 # p_align
+
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x0000e000|0x00001000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00040000|0x00001000
+!endif
+#NV_EVENT_LOG
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x0000f000|0x00001000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00041000|0x00001000
+!endif
+#NV_FTW_WORKING
+DATA = {
+ # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = gEdkiiWorkingBlockSignatureGuid =
+ # { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95 }}
+ 0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
+ 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95,
+ # Crc:UINT32 #WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
+ 0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
+ # WriteQueueSize: UINT64
+ 0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x00010000|0x00010000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00042000|0x00042000
+!endif
+#NV_FTW_SPARE
+
$(VARS_SIZE)|$(FVMAIN_SIZE)
FV = FVMAIN_COMPACT
--git a/generate_elf_header.c b/generate_elf_header.c
new file mode 100644
index 0000000000..5bb87df0d6
--- /dev/null
+++ b/generate_elf_header.c
@@ -0,0 +1,78 @@
+#include "elf.h"
+#include "stdio.h"
+#include "stddef.h"
+
+/*
+ * TODO:
+ * this header will need a XEN_ELFNOTE_PHYS32_ENTRY
+ * right now, it works without, but that might change.
+ */
+
+void print_hdr(void *s, size_t size) {
+ char *c = s;
+
+ while (size--) {
+ printf("0x%02hhx, ", *(c++));
+ }
+}
+int main(void){
+ // FW_SIZE
+ size_t ovmf_blob_size = 0x00200000;
+ // Load OVMF at 1MB when running as PVH guest
+ uint32_t ovmf_base_address = 0x00100000;
+
+ /* ELF file header */
+ Elf32_Ehdr hdr = {
+ .e_ident = ELFMAG,
+ .e_type = ET_EXEC,
+ .e_machine = EM_386,
+ .e_version = EV_CURRENT,
+ // PVH entry point
+ .e_entry = ovmf_base_address + ovmf_blob_size - 0x30,
+ };
+
+ hdr.e_ident[EI_CLASS] = ELFCLASS32;
+ hdr.e_ident[EI_DATA] = ELFDATA2LSB;
+ hdr.e_ident[EI_VERSION] = EV_CURRENT;
+ hdr.e_ident[EI_OSABI] = ELFOSABI_LINUX;
+ hdr.e_flags = R_386_NONE;
+ hdr.e_ehsize = sizeof (hdr);
+ /* about program header */
+ hdr.e_phoff = sizeof (hdr);
+ /* about section header */
+ hdr.e_shentsize = 0;
+ hdr.e_shnum = 0;
+ hdr.e_shstrndx = -1;
+
+ /* program header */
+ Elf32_Phdr phdr = {
+ .p_type = PT_LOAD,
+ .p_offset = 0, // load everything
+ .p_paddr = ovmf_base_address,
+ .p_filesz = ovmf_blob_size,
+ .p_memsz = ovmf_blob_size,
+ .p_flags = PF_X | PF_W | PF_R,
+ .p_align = 0, // is this needed?
+ };
+ phdr.p_vaddr = phdr.p_paddr;
+
+ hdr.e_phnum += 1;
+ hdr.e_phentsize += sizeof (phdr);
+
+ /* section header */
+ Elf32_Shdr shdr = {
+ };
+
+ size_t hdr_size = sizeof(hdr);
+ size_t entry_off = offsetof(typeof(hdr), e_entry);
+ printf("# ELF file header\n");
+ print_hdr(&hdr, entry_off);
+ printf("\n# hdr.e_entry\n");
+ print_hdr(&hdr.e_entry, sizeof(hdr.e_entry));
+ printf("\n# the rest\n");
+ print_hdr(&hdr.e_entry + 1, hdr_size - entry_off - sizeof(hdr.e_entry));
+ printf("\n# Program segment header\n");
+ print_hdr(&phdr, sizeof (phdr));
+
+ return 0;
+}
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 05/31] OvmfPkg/XenOvmf: Creating an ELF header
@ 2019-04-11 10:43 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 10:43 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This header replace the embedded variable store.
>
> The ELF header explain to a loader to load the binary at the address
> 1MB, then jump to the PVH entry point which will be created in a later
> patch.
>
> That patch include generate_elf_header.c which can be use to regenerate
> the ELF header, but this will be a manual step.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> This "ELF header" might not be the best way, but with it the Xen
> toolstack can load OVMF like any other PVH-compatible kernel without
> modification. Is there a better way?
>
> The generate_elf_header.c file was used to generate the series of hex
> number. It isn't at a right place but I'm not sure where to put this C
> file. Maybe in the commit message or maybe it could be forgotten since
> I've added all the comments in the .fdf file.
>
> OvmfPkg/XenOvmf.fdf | 82 +++++++++++++++++++-
> generate_elf_header.c | 78 +++++++++++++++++++
> 2 files changed, 157 insertions(+), 3 deletions(-)
Some things need to be fixed for sure; some other things you might want
to explore as possible improvements.
Generators (that need to be run manually) are perfectly fine.
"must":
(1) The location (the root dir) of this file is inappropriate. It needs
to go under OvmfPkg, and it must state Xen in the name somewhere. I
think right under OvmfPkg/ is fine, because that's where the FDF /
FDF-include files are too.
Also, the filename should use CamelCase.
(2) The generator must definitely include a copyright notice and a
license (preferably an SPDX license identifier).
If you diverge from BSD-2-Clause-Patent, then you might want to mention
this exception in OvmfPkg/License.txt too. (I got some other patches
pending for that, so please check those if you can.)
(3) Near the hex array in the FDF file, there should be a reminder about
the section being generated, and preferably a pointer to the generator.
See for example the top of "OvmfPkg/QemuVideoDxe/VbeShim.h".
Possible improvements:
(4) Document, at the top of the generator, how the generator is supposed
to be built & run, and what packages (if any) it requires. It's fine if
those instructions are OS/distro specific.
(5) If you rewrote the generatory in python, perl, or shell, it could be
easier to use.
(6) I vaguely recall that we can now use C-like structs in DATA regions
in the FDF files. I've never tried it myself, and now I can't find
anything related in the TianoCore bugzilla, the FDF spec, or the
BaseTools git history. If you wanted to research this, you'd have to
talk to the BaseTools maintainers.
If you fix (1) through (3) and ignore the rest, I'll be OK to ACK the patch.
Thanks,
Laszlo
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index 295e30ca3f..20ebacd673 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -21,8 +21,8 @@ [Defines]
> !include OvmfPkg.fdf.inc
>
> #
> -# Build the variable store and the firmware code as one unified flash device
> -# image.
> +# This will allow the flash device image to be recognize as an ELF, with first
> +# an ELF headers, then the firmware code.
> #
> [FD.OVMF]
> BaseAddress = $(FW_BASE_ADDRESS)
> @@ -31,7 +31,83 @@ [FD.OVMF]
> BlockSize = $(BLOCK_SIZE)
> NumBlocks = $(FW_BLOCKS)
>
> -!include VarStore.fdf.inc
> +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
> +0x00000000|0x0000e000
> +!endif
> +!if $(FD_SIZE_IN_KB) == 4096
> +0x00000000|0x00040000
> +!endif
> +#was NV_VARIABLE_STORE
> +DATA = {
> + # ELF file header
> + 0x7f, 0x45, 0x4c, 0x46, # e_ident[0..3]: Magic number
> + 0x01, # File class: 32-bit objects
> + 0x01, # Data encoding: 2's complement, little endian
> + 0x01, # File version
> + 0x03, # OS ABI identification: Object uses GNU ELF extensions
> + 0x00, # ABI version
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, # e_ident[EI_PAD...]
> +
> + 0x02, 0x00, # e_type = Executable file
> + 0x03, 0x00, # e_machine = Intel 80386
> + 0x01, 0x00, 0x00, 0x00, # e_version
> + 0xd0, 0xff, 0x2f, 0x00, # e_entry: Entry point virtual address
> + 0x34, 0x00, 0x00, 0x00, # e_phoff: Program header table file offset
> + 0x00, 0x00, 0x00, 0x00, # e_shoff: Section header table file offset
> + 0x00, 0x00, 0x00, 0x00, # e_flags: Processor-specific flags
> + 0x34, 0x00, # e_ehsize: ELF header size
> + 0x20, 0x00, # e_phentsize: Program header table entry size
> + 0x01, 0x00, # e_phnum: Program header table entry count
> + 0x00, 0x00, # e_shentsize: Section header table entry size
> + 0x00, 0x00, # e_shnum: Section header table entry count
> + 0xff, 0xff, # e_shstrndx
> +
> + # ELF Program segment header
> + 0x01, 0x00, 0x00, 0x00, # p_type = Loadable program segment
> + 0x00, 0x00, 0x00, 0x00, # p_offset
> + 0x00, 0x00, 0x10, 0x00, # p_vaddr: Segment virtual address
> + 0x00, 0x00, 0x10, 0x00, # p_paddr: Segment physical address
> + 0x00, 0x00, 0x20, 0x00, # p_filesz: Segment size in file
> + 0x00, 0x00, 0x20, 0x00, # p_memsz: Segment size in memory
> + 0x07, 0x00, 0x00, 0x00, # p_flags = Segment is executable | writable | readable
> + 0x00, 0x00, 0x00, 0x00 # p_align
> +
> +}
> +
> +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
> +0x0000e000|0x00001000
> +!endif
> +!if $(FD_SIZE_IN_KB) == 4096
> +0x00040000|0x00001000
> +!endif
> +#NV_EVENT_LOG
> +
> +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
> +0x0000f000|0x00001000
> +!endif
> +!if $(FD_SIZE_IN_KB) == 4096
> +0x00041000|0x00001000
> +!endif
> +#NV_FTW_WORKING
> +DATA = {
> + # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = gEdkiiWorkingBlockSignatureGuid =
> + # { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95 }}
> + 0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
> + 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95,
> + # Crc:UINT32 #WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
> + 0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
> + # WriteQueueSize: UINT64
> + 0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
> +}
> +
> +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
> +0x00010000|0x00010000
> +!endif
> +!if $(FD_SIZE_IN_KB) == 4096
> +0x00042000|0x00042000
> +!endif
> +#NV_FTW_SPARE
> +
>
> $(VARS_SIZE)|$(FVMAIN_SIZE)
> FV = FVMAIN_COMPACT
> diff --git a/generate_elf_header.c b/generate_elf_header.c
> new file mode 100644
> index 0000000000..5bb87df0d6
> --- /dev/null
> +++ b/generate_elf_header.c
> @@ -0,0 +1,78 @@
> +#include "elf.h"
> +#include "stdio.h"
> +#include "stddef.h"
> +
> +/*
> + * TODO:
> + * this header will need a XEN_ELFNOTE_PHYS32_ENTRY
> + * right now, it works without, but that might change.
> + */
> +
> +void print_hdr(void *s, size_t size) {
> + char *c = s;
> +
> + while (size--) {
> + printf("0x%02hhx, ", *(c++));
> + }
> +}
> +int main(void){
> + // FW_SIZE
> + size_t ovmf_blob_size = 0x00200000;
> + // Load OVMF at 1MB when running as PVH guest
> + uint32_t ovmf_base_address = 0x00100000;
> +
> + /* ELF file header */
> + Elf32_Ehdr hdr = {
> + .e_ident = ELFMAG,
> + .e_type = ET_EXEC,
> + .e_machine = EM_386,
> + .e_version = EV_CURRENT,
> + // PVH entry point
> + .e_entry = ovmf_base_address + ovmf_blob_size - 0x30,
> + };
> +
> + hdr.e_ident[EI_CLASS] = ELFCLASS32;
> + hdr.e_ident[EI_DATA] = ELFDATA2LSB;
> + hdr.e_ident[EI_VERSION] = EV_CURRENT;
> + hdr.e_ident[EI_OSABI] = ELFOSABI_LINUX;
> + hdr.e_flags = R_386_NONE;
> + hdr.e_ehsize = sizeof (hdr);
> + /* about program header */
> + hdr.e_phoff = sizeof (hdr);
> + /* about section header */
> + hdr.e_shentsize = 0;
> + hdr.e_shnum = 0;
> + hdr.e_shstrndx = -1;
> +
> + /* program header */
> + Elf32_Phdr phdr = {
> + .p_type = PT_LOAD,
> + .p_offset = 0, // load everything
> + .p_paddr = ovmf_base_address,
> + .p_filesz = ovmf_blob_size,
> + .p_memsz = ovmf_blob_size,
> + .p_flags = PF_X | PF_W | PF_R,
> + .p_align = 0, // is this needed?
> + };
> + phdr.p_vaddr = phdr.p_paddr;
> +
> + hdr.e_phnum += 1;
> + hdr.e_phentsize += sizeof (phdr);
> +
> + /* section header */
> + Elf32_Shdr shdr = {
> + };
> +
> + size_t hdr_size = sizeof(hdr);
> + size_t entry_off = offsetof(typeof(hdr), e_entry);
> + printf("# ELF file header\n");
> + print_hdr(&hdr, entry_off);
> + printf("\n# hdr.e_entry\n");
> + print_hdr(&hdr.e_entry, sizeof(hdr.e_entry));
> + printf("\n# the rest\n");
> + print_hdr(&hdr.e_entry + 1, hdr_size - entry_off - sizeof(hdr.e_entry));
> + printf("\n# Program segment header\n");
> + print_hdr(&phdr, sizeof (phdr));
> +
> + return 0;
> +}
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 05/31] OvmfPkg/XenOvmf: Creating an ELF header
@ 2019-04-11 10:43 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 10:43 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This header replace the embedded variable store.
>
> The ELF header explain to a loader to load the binary at the address
> 1MB, then jump to the PVH entry point which will be created in a later
> patch.
>
> That patch include generate_elf_header.c which can be use to regenerate
> the ELF header, but this will be a manual step.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> This "ELF header" might not be the best way, but with it the Xen
> toolstack can load OVMF like any other PVH-compatible kernel without
> modification. Is there a better way?
>
> The generate_elf_header.c file was used to generate the series of hex
> number. It isn't at a right place but I'm not sure where to put this C
> file. Maybe in the commit message or maybe it could be forgotten since
> I've added all the comments in the .fdf file.
>
> OvmfPkg/XenOvmf.fdf | 82 +++++++++++++++++++-
> generate_elf_header.c | 78 +++++++++++++++++++
> 2 files changed, 157 insertions(+), 3 deletions(-)
Some things need to be fixed for sure; some other things you might want
to explore as possible improvements.
Generators (that need to be run manually) are perfectly fine.
"must":
(1) The location (the root dir) of this file is inappropriate. It needs
to go under OvmfPkg, and it must state Xen in the name somewhere. I
think right under OvmfPkg/ is fine, because that's where the FDF /
FDF-include files are too.
Also, the filename should use CamelCase.
(2) The generator must definitely include a copyright notice and a
license (preferably an SPDX license identifier).
If you diverge from BSD-2-Clause-Patent, then you might want to mention
this exception in OvmfPkg/License.txt too. (I got some other patches
pending for that, so please check those if you can.)
(3) Near the hex array in the FDF file, there should be a reminder about
the section being generated, and preferably a pointer to the generator.
See for example the top of "OvmfPkg/QemuVideoDxe/VbeShim.h".
Possible improvements:
(4) Document, at the top of the generator, how the generator is supposed
to be built & run, and what packages (if any) it requires. It's fine if
those instructions are OS/distro specific.
(5) If you rewrote the generatory in python, perl, or shell, it could be
easier to use.
(6) I vaguely recall that we can now use C-like structs in DATA regions
in the FDF files. I've never tried it myself, and now I can't find
anything related in the TianoCore bugzilla, the FDF spec, or the
BaseTools git history. If you wanted to research this, you'd have to
talk to the BaseTools maintainers.
If you fix (1) through (3) and ignore the rest, I'll be OK to ACK the patch.
Thanks,
Laszlo
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index 295e30ca3f..20ebacd673 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -21,8 +21,8 @@ [Defines]
> !include OvmfPkg.fdf.inc
>
> #
> -# Build the variable store and the firmware code as one unified flash device
> -# image.
> +# This will allow the flash device image to be recognize as an ELF, with first
> +# an ELF headers, then the firmware code.
> #
> [FD.OVMF]
> BaseAddress = $(FW_BASE_ADDRESS)
> @@ -31,7 +31,83 @@ [FD.OVMF]
> BlockSize = $(BLOCK_SIZE)
> NumBlocks = $(FW_BLOCKS)
>
> -!include VarStore.fdf.inc
> +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
> +0x00000000|0x0000e000
> +!endif
> +!if $(FD_SIZE_IN_KB) == 4096
> +0x00000000|0x00040000
> +!endif
> +#was NV_VARIABLE_STORE
> +DATA = {
> + # ELF file header
> + 0x7f, 0x45, 0x4c, 0x46, # e_ident[0..3]: Magic number
> + 0x01, # File class: 32-bit objects
> + 0x01, # Data encoding: 2's complement, little endian
> + 0x01, # File version
> + 0x03, # OS ABI identification: Object uses GNU ELF extensions
> + 0x00, # ABI version
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, # e_ident[EI_PAD...]
> +
> + 0x02, 0x00, # e_type = Executable file
> + 0x03, 0x00, # e_machine = Intel 80386
> + 0x01, 0x00, 0x00, 0x00, # e_version
> + 0xd0, 0xff, 0x2f, 0x00, # e_entry: Entry point virtual address
> + 0x34, 0x00, 0x00, 0x00, # e_phoff: Program header table file offset
> + 0x00, 0x00, 0x00, 0x00, # e_shoff: Section header table file offset
> + 0x00, 0x00, 0x00, 0x00, # e_flags: Processor-specific flags
> + 0x34, 0x00, # e_ehsize: ELF header size
> + 0x20, 0x00, # e_phentsize: Program header table entry size
> + 0x01, 0x00, # e_phnum: Program header table entry count
> + 0x00, 0x00, # e_shentsize: Section header table entry size
> + 0x00, 0x00, # e_shnum: Section header table entry count
> + 0xff, 0xff, # e_shstrndx
> +
> + # ELF Program segment header
> + 0x01, 0x00, 0x00, 0x00, # p_type = Loadable program segment
> + 0x00, 0x00, 0x00, 0x00, # p_offset
> + 0x00, 0x00, 0x10, 0x00, # p_vaddr: Segment virtual address
> + 0x00, 0x00, 0x10, 0x00, # p_paddr: Segment physical address
> + 0x00, 0x00, 0x20, 0x00, # p_filesz: Segment size in file
> + 0x00, 0x00, 0x20, 0x00, # p_memsz: Segment size in memory
> + 0x07, 0x00, 0x00, 0x00, # p_flags = Segment is executable | writable | readable
> + 0x00, 0x00, 0x00, 0x00 # p_align
> +
> +}
> +
> +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
> +0x0000e000|0x00001000
> +!endif
> +!if $(FD_SIZE_IN_KB) == 4096
> +0x00040000|0x00001000
> +!endif
> +#NV_EVENT_LOG
> +
> +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
> +0x0000f000|0x00001000
> +!endif
> +!if $(FD_SIZE_IN_KB) == 4096
> +0x00041000|0x00001000
> +!endif
> +#NV_FTW_WORKING
> +DATA = {
> + # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = gEdkiiWorkingBlockSignatureGuid =
> + # { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95 }}
> + 0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
> + 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95,
> + # Crc:UINT32 #WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
> + 0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
> + # WriteQueueSize: UINT64
> + 0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
> +}
> +
> +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
> +0x00010000|0x00010000
> +!endif
> +!if $(FD_SIZE_IN_KB) == 4096
> +0x00042000|0x00042000
> +!endif
> +#NV_FTW_SPARE
> +
>
> $(VARS_SIZE)|$(FVMAIN_SIZE)
> FV = FVMAIN_COMPACT
> diff --git a/generate_elf_header.c b/generate_elf_header.c
> new file mode 100644
> index 0000000000..5bb87df0d6
> --- /dev/null
> +++ b/generate_elf_header.c
> @@ -0,0 +1,78 @@
> +#include "elf.h"
> +#include "stdio.h"
> +#include "stddef.h"
> +
> +/*
> + * TODO:
> + * this header will need a XEN_ELFNOTE_PHYS32_ENTRY
> + * right now, it works without, but that might change.
> + */
> +
> +void print_hdr(void *s, size_t size) {
> + char *c = s;
> +
> + while (size--) {
> + printf("0x%02hhx, ", *(c++));
> + }
> +}
> +int main(void){
> + // FW_SIZE
> + size_t ovmf_blob_size = 0x00200000;
> + // Load OVMF at 1MB when running as PVH guest
> + uint32_t ovmf_base_address = 0x00100000;
> +
> + /* ELF file header */
> + Elf32_Ehdr hdr = {
> + .e_ident = ELFMAG,
> + .e_type = ET_EXEC,
> + .e_machine = EM_386,
> + .e_version = EV_CURRENT,
> + // PVH entry point
> + .e_entry = ovmf_base_address + ovmf_blob_size - 0x30,
> + };
> +
> + hdr.e_ident[EI_CLASS] = ELFCLASS32;
> + hdr.e_ident[EI_DATA] = ELFDATA2LSB;
> + hdr.e_ident[EI_VERSION] = EV_CURRENT;
> + hdr.e_ident[EI_OSABI] = ELFOSABI_LINUX;
> + hdr.e_flags = R_386_NONE;
> + hdr.e_ehsize = sizeof (hdr);
> + /* about program header */
> + hdr.e_phoff = sizeof (hdr);
> + /* about section header */
> + hdr.e_shentsize = 0;
> + hdr.e_shnum = 0;
> + hdr.e_shstrndx = -1;
> +
> + /* program header */
> + Elf32_Phdr phdr = {
> + .p_type = PT_LOAD,
> + .p_offset = 0, // load everything
> + .p_paddr = ovmf_base_address,
> + .p_filesz = ovmf_blob_size,
> + .p_memsz = ovmf_blob_size,
> + .p_flags = PF_X | PF_W | PF_R,
> + .p_align = 0, // is this needed?
> + };
> + phdr.p_vaddr = phdr.p_paddr;
> +
> + hdr.e_phnum += 1;
> + hdr.e_phentsize += sizeof (phdr);
> +
> + /* section header */
> + Elf32_Shdr shdr = {
> + };
> +
> + size_t hdr_size = sizeof(hdr);
> + size_t entry_off = offsetof(typeof(hdr), e_entry);
> + printf("# ELF file header\n");
> + print_hdr(&hdr, entry_off);
> + printf("\n# hdr.e_entry\n");
> + print_hdr(&hdr.e_entry, sizeof(hdr.e_entry));
> + printf("\n# the rest\n");
> + print_hdr(&hdr.e_entry + 1, hdr_size - entry_off - sizeof(hdr.e_entry));
> + printf("\n# Program segment header\n");
> + print_hdr(&phdr, sizeof (phdr));
> +
> + return 0;
> +}
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This one enter directly in 32bits
Information on the expected state of the machine when this entry point
is used can be found at:
https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
{UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia16/ResetVectorVtf0.asm | 18 +++++++-
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 47 ++++++++++++++++++++
OvmfPkg/XenResetVector/XenResetVector.nasmb | 1 +
3 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
similarity index 76%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
copy to OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
index 142d9f3212..46eec66859 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
+++ b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
@@ -3,6 +3,8 @@
; First code executed by processor after resetting.
;
; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
@@ -27,9 +29,23 @@ ALIGN 16
; located just below 0x100000000 (4GB) in the firmware device.
;
%ifdef ALIGN_TOP_TO_4K_FOR_PAGING
- TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0
+ TIMES (0x1000 - ($ - EndOfPageTables) - (fourGigabytes - xenPVHEntryPoint)) DB 0
%endif
+BITS 32
+xenPVHEntryPoint:
+;
+; Entry point to use when running as a Xen PVH guest. (0xffffffd0)
+;
+; Description of the expected state of the machine when this entry point is
+; used can be found at:
+; https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
+;
+ jmp xenPVHMain
+
+BITS 16
+ALIGN 16
+
applicationProcessorEntryPoint:
;
; Application Processors entry point
diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
new file mode 100644
index 0000000000..c4802bf4d1
--- /dev/null
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -0,0 +1,47 @@
+;------------------------------------------------------------------------------
+; @file
+; An entry point use by Xen when a guest is started in PVH mode.
+;
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
+; This program and the accompanying materials are licensed and made available
+; under the terms and conditions of the BSD License which accompanies this
+; distribution. The full text of the license may be found at
+; http://opensource.org/licenses/bsd-license.php
+;
+; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+; WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+;
+;------------------------------------------------------------------------------
+
+BITS 32
+
+xenPVHMain:
+ mov di, 'BP'
+
+ ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
+ mov esp, eax
+
+ cli
+
+ mov ebx, ADDR_OF(gdtr)
+ lgdt [ebx]
+
+ mov eax, SEC_DEFAULT_CR0
+ mov cr0, eax
+
+ jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
+.jmpToNewCodeSeg:
+
+ mov eax, SEC_DEFAULT_CR4
+ mov cr4, eax
+
+ mov ax, LINEAR_SEL
+ mov ds, ax
+ mov es, ax
+ mov fs, ax
+ mov gs, ax
+ mov ss, ax
+
+ ; return to the Main16
+ OneTimeCallRet TransitionFromReal16To32BitFlat
diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
index 49f2bab001..d5a791c139 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
+++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
@@ -70,6 +70,7 @@
%include "Ia16/Init16.asm"
%include "Main.asm"
+%include "Ia32/XenPVHMain.asm"
%include "Ia16/ResetVectorVtf0.asm"
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This one enter directly in 32bits
Information on the expected state of the machine when this entry point
is used can be found at:
https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
{UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia16/ResetVectorVtf0.asm | 18 +++++++-
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 47 ++++++++++++++++++++
OvmfPkg/XenResetVector/XenResetVector.nasmb | 1 +
3 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
similarity index 76%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
copy to OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
index 142d9f3212..46eec66859 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
+++ b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
@@ -3,6 +3,8 @@
; First code executed by processor after resetting.
;
; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
@@ -27,9 +29,23 @@ ALIGN 16
; located just below 0x100000000 (4GB) in the firmware device.
;
%ifdef ALIGN_TOP_TO_4K_FOR_PAGING
- TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0
+ TIMES (0x1000 - ($ - EndOfPageTables) - (fourGigabytes - xenPVHEntryPoint)) DB 0
%endif
+BITS 32
+xenPVHEntryPoint:
+;
+; Entry point to use when running as a Xen PVH guest. (0xffffffd0)
+;
+; Description of the expected state of the machine when this entry point is
+; used can be found at:
+; https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
+;
+ jmp xenPVHMain
+
+BITS 16
+ALIGN 16
+
applicationProcessorEntryPoint:
;
; Application Processors entry point
diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
new file mode 100644
index 0000000000..c4802bf4d1
--- /dev/null
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -0,0 +1,47 @@
+;------------------------------------------------------------------------------
+; @file
+; An entry point use by Xen when a guest is started in PVH mode.
+;
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
+; This program and the accompanying materials are licensed and made available
+; under the terms and conditions of the BSD License which accompanies this
+; distribution. The full text of the license may be found at
+; http://opensource.org/licenses/bsd-license.php
+;
+; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+; WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+;
+;------------------------------------------------------------------------------
+
+BITS 32
+
+xenPVHMain:
+ mov di, 'BP'
+
+ ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
+ mov esp, eax
+
+ cli
+
+ mov ebx, ADDR_OF(gdtr)
+ lgdt [ebx]
+
+ mov eax, SEC_DEFAULT_CR0
+ mov cr0, eax
+
+ jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
+.jmpToNewCodeSeg:
+
+ mov eax, SEC_DEFAULT_CR4
+ mov cr4, eax
+
+ mov ax, LINEAR_SEL
+ mov ds, ax
+ mov es, ax
+ mov fs, ax
+ mov gs, ax
+ mov ss, ax
+
+ ; return to the Main16
+ OneTimeCallRet TransitionFromReal16To32BitFlat
diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
index 49f2bab001..d5a791c139 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
+++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
@@ -70,6 +70,7 @@
%include "Ia16/Init16.asm"
%include "Main.asm"
+%include "Ia32/XenPVHMain.asm"
%include "Ia16/ResetVectorVtf0.asm"
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
@ 2019-04-11 10:49 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 10:49 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This one enter directly in 32bits
(1) I probably mentioned this elsewhere, but it bears repeating (it
applies to all patches): please don't start the body of the commit
message mid-sentence or mid-paragraph. The body should be self-contained.
> Information on the expected state of the machine when this entry point
> is used can be found at:
> https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> {UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia16/ResetVectorVtf0.asm | 18 +++++++-
> OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 47 ++++++++++++++++++++
> OvmfPkg/XenResetVector/XenResetVector.nasmb | 1 +
> 3 files changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> similarity index 76%
> copy from UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
> copy to OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> index 142d9f3212..46eec66859 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
> +++ b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> @@ -3,6 +3,8 @@
> ; First code executed by processor after resetting.
> ;
> ; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
(2) Probably also mentioned elsewhere, but all the new files should come
with SPDX license IDs, if possible. (Once you rebase, such omissions
will become apparent anyway, because the copy-origin files now carry
SPDX IDs, but the copies you created earlier don't, and that will
present itself as a difference with --find-copies-harder.)
With the above two formalities fixed:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
> @@ -27,9 +29,23 @@ ALIGN 16
> ; located just below 0x100000000 (4GB) in the firmware device.
> ;
> %ifdef ALIGN_TOP_TO_4K_FOR_PAGING
> - TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0
> + TIMES (0x1000 - ($ - EndOfPageTables) - (fourGigabytes - xenPVHEntryPoint)) DB 0
> %endif
>
> +BITS 32
> +xenPVHEntryPoint:
> +;
> +; Entry point to use when running as a Xen PVH guest. (0xffffffd0)
> +;
> +; Description of the expected state of the machine when this entry point is
> +; used can be found at:
> +; https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
> +;
> + jmp xenPVHMain
> +
> +BITS 16
> +ALIGN 16
> +
> applicationProcessorEntryPoint:
> ;
> ; Application Processors entry point
> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> new file mode 100644
> index 0000000000..c4802bf4d1
> --- /dev/null
> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> @@ -0,0 +1,47 @@
> +;------------------------------------------------------------------------------
> +; @file
> +; An entry point use by Xen when a guest is started in PVH mode.
> +;
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> +; This program and the accompanying materials are licensed and made available
> +; under the terms and conditions of the BSD License which accompanies this
> +; distribution. The full text of the license may be found at
> +; http://opensource.org/licenses/bsd-license.php
> +;
> +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
> +; WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +;
> +;------------------------------------------------------------------------------
> +
> +BITS 32
> +
> +xenPVHMain:
> + mov di, 'BP'
> +
> + ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> + mov esp, eax
> +
> + cli
> +
> + mov ebx, ADDR_OF(gdtr)
> + lgdt [ebx]
> +
> + mov eax, SEC_DEFAULT_CR0
> + mov cr0, eax
> +
> + jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
> +.jmpToNewCodeSeg:
> +
> + mov eax, SEC_DEFAULT_CR4
> + mov cr4, eax
> +
> + mov ax, LINEAR_SEL
> + mov ds, ax
> + mov es, ax
> + mov fs, ax
> + mov gs, ax
> + mov ss, ax
> +
> + ; return to the Main16
> + OneTimeCallRet TransitionFromReal16To32BitFlat
> diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> index 49f2bab001..d5a791c139 100644
> --- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
> +++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> @@ -70,6 +70,7 @@
> %include "Ia16/Init16.asm"
>
> %include "Main.asm"
> +%include "Ia32/XenPVHMain.asm"
>
> %include "Ia16/ResetVectorVtf0.asm"
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
@ 2019-04-11 10:49 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 10:49 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This one enter directly in 32bits
(1) I probably mentioned this elsewhere, but it bears repeating (it
applies to all patches): please don't start the body of the commit
message mid-sentence or mid-paragraph. The body should be self-contained.
> Information on the expected state of the machine when this entry point
> is used can be found at:
> https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> {UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia16/ResetVectorVtf0.asm | 18 +++++++-
> OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 47 ++++++++++++++++++++
> OvmfPkg/XenResetVector/XenResetVector.nasmb | 1 +
> 3 files changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> similarity index 76%
> copy from UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
> copy to OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> index 142d9f3212..46eec66859 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
> +++ b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> @@ -3,6 +3,8 @@
> ; First code executed by processor after resetting.
> ;
> ; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
(2) Probably also mentioned elsewhere, but all the new files should come
with SPDX license IDs, if possible. (Once you rebase, such omissions
will become apparent anyway, because the copy-origin files now carry
SPDX IDs, but the copies you created earlier don't, and that will
present itself as a difference with --find-copies-harder.)
With the above two formalities fixed:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
> @@ -27,9 +29,23 @@ ALIGN 16
> ; located just below 0x100000000 (4GB) in the firmware device.
> ;
> %ifdef ALIGN_TOP_TO_4K_FOR_PAGING
> - TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0
> + TIMES (0x1000 - ($ - EndOfPageTables) - (fourGigabytes - xenPVHEntryPoint)) DB 0
> %endif
>
> +BITS 32
> +xenPVHEntryPoint:
> +;
> +; Entry point to use when running as a Xen PVH guest. (0xffffffd0)
> +;
> +; Description of the expected state of the machine when this entry point is
> +; used can be found at:
> +; https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
> +;
> + jmp xenPVHMain
> +
> +BITS 16
> +ALIGN 16
> +
> applicationProcessorEntryPoint:
> ;
> ; Application Processors entry point
> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> new file mode 100644
> index 0000000000..c4802bf4d1
> --- /dev/null
> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> @@ -0,0 +1,47 @@
> +;------------------------------------------------------------------------------
> +; @file
> +; An entry point use by Xen when a guest is started in PVH mode.
> +;
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> +; This program and the accompanying materials are licensed and made available
> +; under the terms and conditions of the BSD License which accompanies this
> +; distribution. The full text of the license may be found at
> +; http://opensource.org/licenses/bsd-license.php
> +;
> +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
> +; WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +;
> +;------------------------------------------------------------------------------
> +
> +BITS 32
> +
> +xenPVHMain:
> + mov di, 'BP'
> +
> + ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> + mov esp, eax
> +
> + cli
> +
> + mov ebx, ADDR_OF(gdtr)
> + lgdt [ebx]
> +
> + mov eax, SEC_DEFAULT_CR0
> + mov cr0, eax
> +
> + jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
> +.jmpToNewCodeSeg:
> +
> + mov eax, SEC_DEFAULT_CR4
> + mov cr4, eax
> +
> + mov ax, LINEAR_SEL
> + mov ds, ax
> + mov es, ax
> + mov fs, ax
> + mov gs, ax
> + mov ss, ax
> +
> + ; return to the Main16
> + OneTimeCallRet TransitionFromReal16To32BitFlat
> diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> index 49f2bab001..d5a791c139 100644
> --- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
> +++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> @@ -70,6 +70,7 @@
> %include "Ia16/Init16.asm"
>
> %include "Main.asm"
> +%include "Ia32/XenPVHMain.asm"
>
> %include "Ia16/ResetVectorVtf0.asm"
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
@ 2019-04-11 12:52 ` Andrew Cooper
0 siblings, 0 replies; 168+ messages in thread
From: Andrew Cooper @ 2019-04-11 12:52 UTC (permalink / raw)
To: Anthony PERARD, devel
Cc: Jordan Justen, Julien Grall, Laszlo Ersek, xen-devel, Ard Biesheuvel
On 09/04/2019 12:08, Anthony PERARD wrote:
> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> new file mode 100644
> index 0000000000..c4802bf4d1
> --- /dev/null
> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> @@ -0,0 +1,47 @@
> +;------------------------------------------------------------------------------
> +; @file
> +; An entry point use by Xen when a guest is started in PVH mode.
> +;
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> +; This program and the accompanying materials are licensed and made available
> +; under the terms and conditions of the BSD License which accompanies this
> +; distribution. The full text of the license may be found at
> +; http://opensource.org/licenses/bsd-license.php
> +;
> +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
> +; WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +;
> +;------------------------------------------------------------------------------
> +
> +BITS 32
> +
> +xenPVHMain:
> + mov di, 'BP'
> +
> + ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> + mov esp, eax
Where is the ABI described? Xen has no BIST, so this will always have
the value 0. Stashing it in the stack pointer seems like a weird choice,
and a recipe for subtle bugs.
> +
> + cli
Interrupts are guaranteed to be off at this point.
> +
> + mov ebx, ADDR_OF(gdtr)
> + lgdt [ebx]
lgdt ADDR_OF(gdtr), presumably?
This is 32bit code - there is no need for any indirection through
registers for memory operands.
> +
> + mov eax, SEC_DEFAULT_CR0
> + mov cr0, eax
> +
> + jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
> +.jmpToNewCodeSeg:
> +
> + mov eax, SEC_DEFAULT_CR4
> + mov cr4, eax
> +
> + mov ax, LINEAR_SEL
> + mov ds, ax
> + mov es, ax
> + mov fs, ax
> + mov gs, ax
> + mov ss, ax
> +
> + ; return to the Main16
> + OneTimeCallRet TransitionFromReal16To32BitFlat
Is there any description of what OneTimeCallRet is, and why a simple jmp
wont do?
Irrespective of that, you're moving to a function whose name suggests it
is in 16bit mode, while you are currently in 32bit flat mode.
(SEC_DEFAULT_CR0 has PE set, and LINEAR_SEL is 32bit flat. This clearly
isn't correct, but surely we want to skip all the 16bit setup, as well.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [Xen-devel] [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
@ 2019-04-11 12:52 ` Andrew Cooper
0 siblings, 0 replies; 168+ messages in thread
From: Andrew Cooper @ 2019-04-11 12:52 UTC (permalink / raw)
To: Anthony PERARD, devel
Cc: Jordan Justen, Julien Grall, Laszlo Ersek, xen-devel, Ard Biesheuvel
On 09/04/2019 12:08, Anthony PERARD wrote:
> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> new file mode 100644
> index 0000000000..c4802bf4d1
> --- /dev/null
> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> @@ -0,0 +1,47 @@
> +;------------------------------------------------------------------------------
> +; @file
> +; An entry point use by Xen when a guest is started in PVH mode.
> +;
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> +; This program and the accompanying materials are licensed and made available
> +; under the terms and conditions of the BSD License which accompanies this
> +; distribution. The full text of the license may be found at
> +; http://opensource.org/licenses/bsd-license.php
> +;
> +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
> +; WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +;
> +;------------------------------------------------------------------------------
> +
> +BITS 32
> +
> +xenPVHMain:
> + mov di, 'BP'
> +
> + ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> + mov esp, eax
Where is the ABI described? Xen has no BIST, so this will always have
the value 0. Stashing it in the stack pointer seems like a weird choice,
and a recipe for subtle bugs.
> +
> + cli
Interrupts are guaranteed to be off at this point.
> +
> + mov ebx, ADDR_OF(gdtr)
> + lgdt [ebx]
lgdt ADDR_OF(gdtr), presumably?
This is 32bit code - there is no need for any indirection through
registers for memory operands.
> +
> + mov eax, SEC_DEFAULT_CR0
> + mov cr0, eax
> +
> + jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
> +.jmpToNewCodeSeg:
> +
> + mov eax, SEC_DEFAULT_CR4
> + mov cr4, eax
> +
> + mov ax, LINEAR_SEL
> + mov ds, ax
> + mov es, ax
> + mov fs, ax
> + mov gs, ax
> + mov ss, ax
> +
> + ; return to the Main16
> + OneTimeCallRet TransitionFromReal16To32BitFlat
Is there any description of what OneTimeCallRet is, and why a simple jmp
wont do?
Irrespective of that, you're moving to a function whose name suggests it
is in 16bit mode, while you are currently in 32bit flat mode.
(SEC_DEFAULT_CR0 has PE set, and LINEAR_SEL is 32bit flat. This clearly
isn't correct, but surely we want to skip all the 16bit setup, as well.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
@ 2019-04-15 11:25 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-15 11:25 UTC (permalink / raw)
To: Andrew Cooper
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Thu, Apr 11, 2019 at 01:52:27PM +0100, Andrew Cooper wrote:
> On 09/04/2019 12:08, Anthony PERARD wrote:
> > diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> > new file mode 100644
> > index 0000000000..c4802bf4d1
> > --- /dev/null
> > +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> > @@ -0,0 +1,47 @@
> > +;------------------------------------------------------------------------------
> > +; @file
> > +; An entry point use by Xen when a guest is started in PVH mode.
> > +;
> > +; Copyright (c) 2019, Citrix Systems, Inc.
> > +;
> > +; This program and the accompanying materials are licensed and made available
> > +; under the terms and conditions of the BSD License which accompanies this
> > +; distribution. The full text of the license may be found at
> > +; http://opensource.org/licenses/bsd-license.php
> > +;
> > +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
> > +; WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> > +;
> > +;------------------------------------------------------------------------------
> > +
> > +BITS 32
> > +
> > +xenPVHMain:
> > + mov di, 'BP'
> > +
> > + ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> > + mov esp, eax
>
> Where is the ABI described? Xen has no BIST, so this will always have
> the value 0. Stashing it in the stack pointer seems like a weird choice,
> and a recipe for subtle bugs.
I've just copied over what was done in the HVM case. I'll change that
and ignore the value in `eax'.
> > +
> > + cli
>
> Interrupts are guaranteed to be off at this point.
OK, I'll remove the instruction.
> > +
> > + mov ebx, ADDR_OF(gdtr)
> > + lgdt [ebx]
>
> lgdt ADDR_OF(gdtr), presumably?
>
> This is 32bit code - there is no need for any indirection through
> registers for memory operands.
I'll change this, if it works.
> > +
> > + mov eax, SEC_DEFAULT_CR0
> > + mov cr0, eax
> > +
> > + jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
> > +.jmpToNewCodeSeg:
> > +
> > + mov eax, SEC_DEFAULT_CR4
> > + mov cr4, eax
> > +
> > + mov ax, LINEAR_SEL
> > + mov ds, ax
> > + mov es, ax
> > + mov fs, ax
> > + mov gs, ax
> > + mov ss, ax
> > +
> > + ; return to the Main16
> > + OneTimeCallRet TransitionFromReal16To32BitFlat
>
> Is there any description of what OneTimeCallRet is, and why a simple jmp
> wont do?
That's is used to return to where the `OneTimeCall' macro has been
used. In this assembly, they don't use `call' and `ret', instead there
is a set of two macros:
%macro OneTimeCall 1
jmp %1
%1 %+ OneTimerCallReturn:
%endmacro
%macro OneTimeCallRet 1
jmp %1 %+ OneTimerCallReturn
%endmacro
> Irrespective of that, you're moving to a function whose name suggests it
> is in 16bit mode, while you are currently in 32bit flat mode.
> (SEC_DEFAULT_CR0 has PE set, and LINEAR_SEL is 32bit flat. This clearly
> isn't correct, but surely we want to skip all the 16bit setup, as well.
I think I need to change the comment. Main16 is just a label name for
something that makes several "calls" and transition from 16bits to 32 or
64 before calling the next module in the firmware.
That return simply jmp to the part of the main where we are supposed to
be in 32bit flat mode.
Thanks for the review,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
@ 2019-04-15 11:25 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-15 11:25 UTC (permalink / raw)
To: Andrew Cooper
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Thu, Apr 11, 2019 at 01:52:27PM +0100, Andrew Cooper wrote:
> On 09/04/2019 12:08, Anthony PERARD wrote:
> > diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> > new file mode 100644
> > index 0000000000..c4802bf4d1
> > --- /dev/null
> > +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> > @@ -0,0 +1,47 @@
> > +;------------------------------------------------------------------------------
> > +; @file
> > +; An entry point use by Xen when a guest is started in PVH mode.
> > +;
> > +; Copyright (c) 2019, Citrix Systems, Inc.
> > +;
> > +; This program and the accompanying materials are licensed and made available
> > +; under the terms and conditions of the BSD License which accompanies this
> > +; distribution. The full text of the license may be found at
> > +; http://opensource.org/licenses/bsd-license.php
> > +;
> > +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
> > +; WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> > +;
> > +;------------------------------------------------------------------------------
> > +
> > +BITS 32
> > +
> > +xenPVHMain:
> > + mov di, 'BP'
> > +
> > + ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> > + mov esp, eax
>
> Where is the ABI described? Xen has no BIST, so this will always have
> the value 0. Stashing it in the stack pointer seems like a weird choice,
> and a recipe for subtle bugs.
I've just copied over what was done in the HVM case. I'll change that
and ignore the value in `eax'.
> > +
> > + cli
>
> Interrupts are guaranteed to be off at this point.
OK, I'll remove the instruction.
> > +
> > + mov ebx, ADDR_OF(gdtr)
> > + lgdt [ebx]
>
> lgdt ADDR_OF(gdtr), presumably?
>
> This is 32bit code - there is no need for any indirection through
> registers for memory operands.
I'll change this, if it works.
> > +
> > + mov eax, SEC_DEFAULT_CR0
> > + mov cr0, eax
> > +
> > + jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
> > +.jmpToNewCodeSeg:
> > +
> > + mov eax, SEC_DEFAULT_CR4
> > + mov cr4, eax
> > +
> > + mov ax, LINEAR_SEL
> > + mov ds, ax
> > + mov es, ax
> > + mov fs, ax
> > + mov gs, ax
> > + mov ss, ax
> > +
> > + ; return to the Main16
> > + OneTimeCallRet TransitionFromReal16To32BitFlat
>
> Is there any description of what OneTimeCallRet is, and why a simple jmp
> wont do?
That's is used to return to where the `OneTimeCall' macro has been
used. In this assembly, they don't use `call' and `ret', instead there
is a set of two macros:
%macro OneTimeCall 1
jmp %1
%1 %+ OneTimerCallReturn:
%endmacro
%macro OneTimeCallRet 1
jmp %1 %+ OneTimerCallReturn
%endmacro
> Irrespective of that, you're moving to a function whose name suggests it
> is in 16bit mode, while you are currently in 32bit flat mode.
> (SEC_DEFAULT_CR0 has PE set, and LINEAR_SEL is 32bit flat. This clearly
> isn't correct, but surely we want to skip all the 16bit setup, as well.
I think I need to change the comment. Main16 is just a label name for
something that makes several "calls" and transition from 16bits to 32 or
64 before calling the next module in the firmware.
That return simply jmp to the part of the main where we are supposed to
be in 32bit flat mode.
Thanks for the review,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
@ 2019-04-15 13:28 ` Andrew Cooper
0 siblings, 0 replies; 168+ messages in thread
From: Andrew Cooper @ 2019-04-15 13:28 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On 15/04/2019 12:25, Anthony PERARD wrote:
> On Thu, Apr 11, 2019 at 01:52:27PM +0100, Andrew Cooper wrote:
>> On 09/04/2019 12:08, Anthony PERARD wrote:
>>> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>>> new file mode 100644
>>> index 0000000000..c4802bf4d1
>>> --- /dev/null
>>> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>>> @@ -0,0 +1,47 @@
>>> +;------------------------------------------------------------------------------
>>> +; @file
>>> +; An entry point use by Xen when a guest is started in PVH mode.
>>> +;
>>> +; Copyright (c) 2019, Citrix Systems, Inc.
>>> +;
>>> +; This program and the accompanying materials are licensed and made available
>>> +; under the terms and conditions of the BSD License which accompanies this
>>> +; distribution. The full text of the license may be found at
>>> +; http://opensource.org/licenses/bsd-license.php
>>> +;
>>> +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
>>> +; WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>>> +;
>>> +;------------------------------------------------------------------------------
>>> +
>>> +BITS 32
>>> +
>>> +xenPVHMain:
>>> + mov di, 'BP'
>>> +
>>> + ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
>>> + mov esp, eax
>> Where is the ABI described? Xen has no BIST, so this will always have
>> the value 0. Stashing it in the stack pointer seems like a weird choice,
>> and a recipe for subtle bugs.
> I've just copied over what was done in the HVM case. I'll change that
> and ignore the value in `eax'.
The ASCII BP in %di is also bizarre without an explanation of where it
is intended to be used.
>>> +
>>> + mov eax, SEC_DEFAULT_CR0
>>> + mov cr0, eax
>>> +
>>> + jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
>>> +.jmpToNewCodeSeg:
>>> +
>>> + mov eax, SEC_DEFAULT_CR4
>>> + mov cr4, eax
>>> +
>>> + mov ax, LINEAR_SEL
>>> + mov ds, ax
>>> + mov es, ax
>>> + mov fs, ax
>>> + mov gs, ax
>>> + mov ss, ax
>>> +
>>> + ; return to the Main16
>>> + OneTimeCallRet TransitionFromReal16To32BitFlat
>> Is there any description of what OneTimeCallRet is, and why a simple jmp
>> wont do?
> That's is used to return to where the `OneTimeCall' macro has been
> used. In this assembly, they don't use `call' and `ret', instead there
> is a set of two macros:
>
> %macro OneTimeCall 1
> jmp %1
> %1 %+ OneTimerCallReturn:
> %endmacro
>
> %macro OneTimeCallRet 1
> jmp %1 %+ OneTimerCallReturn
> %endmacro
I found these, but the complete lack of any documentation makes them
entirely opaque, especially as they are not actually call/ret instructions.
Even if they are suppose to be used in matching pairs, OneTimeCall
hasn't been used so far in the PVH code, so where is this going to
actually go to?
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [Xen-devel] [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
@ 2019-04-15 13:28 ` Andrew Cooper
0 siblings, 0 replies; 168+ messages in thread
From: Andrew Cooper @ 2019-04-15 13:28 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On 15/04/2019 12:25, Anthony PERARD wrote:
> On Thu, Apr 11, 2019 at 01:52:27PM +0100, Andrew Cooper wrote:
>> On 09/04/2019 12:08, Anthony PERARD wrote:
>>> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>>> new file mode 100644
>>> index 0000000000..c4802bf4d1
>>> --- /dev/null
>>> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>>> @@ -0,0 +1,47 @@
>>> +;------------------------------------------------------------------------------
>>> +; @file
>>> +; An entry point use by Xen when a guest is started in PVH mode.
>>> +;
>>> +; Copyright (c) 2019, Citrix Systems, Inc.
>>> +;
>>> +; This program and the accompanying materials are licensed and made available
>>> +; under the terms and conditions of the BSD License which accompanies this
>>> +; distribution. The full text of the license may be found at
>>> +; http://opensource.org/licenses/bsd-license.php
>>> +;
>>> +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
>>> +; WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>>> +;
>>> +;------------------------------------------------------------------------------
>>> +
>>> +BITS 32
>>> +
>>> +xenPVHMain:
>>> + mov di, 'BP'
>>> +
>>> + ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
>>> + mov esp, eax
>> Where is the ABI described? Xen has no BIST, so this will always have
>> the value 0. Stashing it in the stack pointer seems like a weird choice,
>> and a recipe for subtle bugs.
> I've just copied over what was done in the HVM case. I'll change that
> and ignore the value in `eax'.
The ASCII BP in %di is also bizarre without an explanation of where it
is intended to be used.
>>> +
>>> + mov eax, SEC_DEFAULT_CR0
>>> + mov cr0, eax
>>> +
>>> + jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
>>> +.jmpToNewCodeSeg:
>>> +
>>> + mov eax, SEC_DEFAULT_CR4
>>> + mov cr4, eax
>>> +
>>> + mov ax, LINEAR_SEL
>>> + mov ds, ax
>>> + mov es, ax
>>> + mov fs, ax
>>> + mov gs, ax
>>> + mov ss, ax
>>> +
>>> + ; return to the Main16
>>> + OneTimeCallRet TransitionFromReal16To32BitFlat
>> Is there any description of what OneTimeCallRet is, and why a simple jmp
>> wont do?
> That's is used to return to where the `OneTimeCall' macro has been
> used. In this assembly, they don't use `call' and `ret', instead there
> is a set of two macros:
>
> %macro OneTimeCall 1
> jmp %1
> %1 %+ OneTimerCallReturn:
> %endmacro
>
> %macro OneTimeCallRet 1
> jmp %1 %+ OneTimerCallReturn
> %endmacro
I found these, but the complete lack of any documentation makes them
entirely opaque, especially as they are not actually call/ret instructions.
Even if they are suppose to be used in matching pairs, OneTimeCall
hasn't been used so far in the PVH code, so where is this going to
actually go to?
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 07/31] OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
As described in the Xen PVH documentation [1], "ebx: contains the
physical memory address where the loader has placed the boot start info
structure". To have this pointer saved to be able to use it later in the
PEI phase, we allocate some space in the MEMFD for it. We use 'XPVH' as
a signature (for "Xen PVH").
[1] https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/OvmfPkg.dec | 4 ++++
OvmfPkg/XenOvmf.fdf | 4 ++++
OvmfPkg/XenResetVector/XenResetVector.inf | 3 +++
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 4 ++++
OvmfPkg/XenResetVector/XenResetVector.nasmb | 2 ++
5 files changed, 17 insertions(+)
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index e50c6179a2..1cbbc49a6b 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -127,6 +127,10 @@ [PcdsFixedAtBuild]
gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
+ # Used by XenOvmf
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr|0x0|UINT32|0x30
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize|0x0|UINT32|0x31
+
[PcdsDynamic, PcdsDynamicEx]
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 20ebacd673..f9e58befd6 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -159,6 +159,10 @@ [FD.MEMFD]
0x007000|0x001000
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
+0x008000|0x001000
+# Used by XenResetVector to communicate with XenPlatformPei
+gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr|gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
+
0x010000|0x010000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
diff --git a/OvmfPkg/XenResetVector/XenResetVector.inf b/OvmfPkg/XenResetVector/XenResetVector.inf
index 5c05f02285..ec98c17876 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.inf
+++ b/OvmfPkg/XenResetVector/XenResetVector.inf
@@ -41,3 +41,6 @@ [BuildOptions]
[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
+
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
index c4802bf4d1..4e55b0ac1f 100644
--- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -22,6 +22,10 @@ xenPVHMain:
; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
mov esp, eax
+ ;; Store "Start of day" struct pointer for later use
+ mov dword[PVH_SPACE (0)], ebx
+ mov dword[PVH_SPACE (4)], 'XPVH'
+
cli
mov ebx, ADDR_OF(gdtr)
diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
index d5a791c139..50cb81fcd1 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
+++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
@@ -41,6 +41,8 @@
%include "CommonMacros.inc"
+%define PVH_SPACE(Offset) (FixedPcdGet32 (PcdXenStartOfDayStructPtr) + (Offset))
+
%include "PostCodes.inc"
%ifdef DEBUG_PORT80
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 07/31] OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
As described in the Xen PVH documentation [1], "ebx: contains the
physical memory address where the loader has placed the boot start info
structure". To have this pointer saved to be able to use it later in the
PEI phase, we allocate some space in the MEMFD for it. We use 'XPVH' as
a signature (for "Xen PVH").
[1] https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/OvmfPkg.dec | 4 ++++
OvmfPkg/XenOvmf.fdf | 4 ++++
OvmfPkg/XenResetVector/XenResetVector.inf | 3 +++
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 4 ++++
OvmfPkg/XenResetVector/XenResetVector.nasmb | 2 ++
5 files changed, 17 insertions(+)
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index e50c6179a2..1cbbc49a6b 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -127,6 +127,10 @@ [PcdsFixedAtBuild]
gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
+ # Used by XenOvmf
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr|0x0|UINT32|0x30
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize|0x0|UINT32|0x31
+
[PcdsDynamic, PcdsDynamicEx]
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 20ebacd673..f9e58befd6 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -159,6 +159,10 @@ [FD.MEMFD]
0x007000|0x001000
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
+0x008000|0x001000
+# Used by XenResetVector to communicate with XenPlatformPei
+gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr|gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
+
0x010000|0x010000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
diff --git a/OvmfPkg/XenResetVector/XenResetVector.inf b/OvmfPkg/XenResetVector/XenResetVector.inf
index 5c05f02285..ec98c17876 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.inf
+++ b/OvmfPkg/XenResetVector/XenResetVector.inf
@@ -41,3 +41,6 @@ [BuildOptions]
[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
+
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
index c4802bf4d1..4e55b0ac1f 100644
--- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -22,6 +22,10 @@ xenPVHMain:
; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
mov esp, eax
+ ;; Store "Start of day" struct pointer for later use
+ mov dword[PVH_SPACE (0)], ebx
+ mov dword[PVH_SPACE (4)], 'XPVH'
+
cli
mov ebx, ADDR_OF(gdtr)
diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
index d5a791c139..50cb81fcd1 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
+++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
@@ -41,6 +41,8 @@
%include "CommonMacros.inc"
+%define PVH_SPACE(Offset) (FixedPcdGet32 (PcdXenStartOfDayStructPtr) + (Offset))
+
%include "PostCodes.inc"
%ifdef DEBUG_PORT80
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 07/31] OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests
@ 2019-04-11 11:09 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:09 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> As described in the Xen PVH documentation [1], "ebx: contains the
> physical memory address where the loader has placed the boot start info
> structure". To have this pointer saved to be able to use it later in the
> PEI phase, we allocate some space in the MEMFD for it. We use 'XPVH' as
> a signature (for "Xen PVH").
>
> [1] https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/OvmfPkg.dec | 4 ++++
> OvmfPkg/XenOvmf.fdf | 4 ++++
> OvmfPkg/XenResetVector/XenResetVector.inf | 3 +++
> OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 4 ++++
> OvmfPkg/XenResetVector/XenResetVector.nasmb | 2 ++
> 5 files changed, 17 insertions(+)
>
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index e50c6179a2..1cbbc49a6b 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -127,6 +127,10 @@ [PcdsFixedAtBuild]
> gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
>
> + # Used by XenOvmf
(1) I suggest dropping this comment (it'd have to be updated to OvmfXen
anyway), and...
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr|0x0|UINT32|0x30
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize|0x0|UINT32|0x31
> +
(2) calling these PcdXenPvh* rather than just PcdXen*
(my understanding is that they are specific to PVH)
(3) Please use token values 0x17 and 0x28. That should decrease the
token space fragmentation.
With those addressed:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
> [PcdsDynamic, PcdsDynamicEx]
> gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index 20ebacd673..f9e58befd6 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -159,6 +159,10 @@ [FD.MEMFD]
> 0x007000|0x001000
> gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
>
> +0x008000|0x001000
> +# Used by XenResetVector to communicate with XenPlatformPei
> +gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr|gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
> +
> 0x010000|0x010000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>
> diff --git a/OvmfPkg/XenResetVector/XenResetVector.inf b/OvmfPkg/XenResetVector/XenResetVector.inf
> index 5c05f02285..ec98c17876 100644
> --- a/OvmfPkg/XenResetVector/XenResetVector.inf
> +++ b/OvmfPkg/XenResetVector/XenResetVector.inf
> @@ -41,3 +41,6 @@ [BuildOptions]
> [Pcd]
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> +
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> index c4802bf4d1..4e55b0ac1f 100644
> --- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> @@ -22,6 +22,10 @@ xenPVHMain:
> ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> mov esp, eax
>
> + ;; Store "Start of day" struct pointer for later use
> + mov dword[PVH_SPACE (0)], ebx
> + mov dword[PVH_SPACE (4)], 'XPVH'
> +
> cli
>
> mov ebx, ADDR_OF(gdtr)
> diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> index d5a791c139..50cb81fcd1 100644
> --- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
> +++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> @@ -41,6 +41,8 @@
>
> %include "CommonMacros.inc"
>
> +%define PVH_SPACE(Offset) (FixedPcdGet32 (PcdXenStartOfDayStructPtr) + (Offset))
> +
> %include "PostCodes.inc"
>
> %ifdef DEBUG_PORT80
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v2 07/31] OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests
@ 2019-04-11 11:09 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:09 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> As described in the Xen PVH documentation [1], "ebx: contains the
> physical memory address where the loader has placed the boot start info
> structure". To have this pointer saved to be able to use it later in the
> PEI phase, we allocate some space in the MEMFD for it. We use 'XPVH' as
> a signature (for "Xen PVH").
>
> [1] https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/OvmfPkg.dec | 4 ++++
> OvmfPkg/XenOvmf.fdf | 4 ++++
> OvmfPkg/XenResetVector/XenResetVector.inf | 3 +++
> OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 4 ++++
> OvmfPkg/XenResetVector/XenResetVector.nasmb | 2 ++
> 5 files changed, 17 insertions(+)
>
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index e50c6179a2..1cbbc49a6b 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -127,6 +127,10 @@ [PcdsFixedAtBuild]
> gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
>
> + # Used by XenOvmf
(1) I suggest dropping this comment (it'd have to be updated to OvmfXen
anyway), and...
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr|0x0|UINT32|0x30
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize|0x0|UINT32|0x31
> +
(2) calling these PcdXenPvh* rather than just PcdXen*
(my understanding is that they are specific to PVH)
(3) Please use token values 0x17 and 0x28. That should decrease the
token space fragmentation.
With those addressed:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
> [PcdsDynamic, PcdsDynamicEx]
> gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index 20ebacd673..f9e58befd6 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -159,6 +159,10 @@ [FD.MEMFD]
> 0x007000|0x001000
> gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
>
> +0x008000|0x001000
> +# Used by XenResetVector to communicate with XenPlatformPei
> +gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr|gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
> +
> 0x010000|0x010000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>
> diff --git a/OvmfPkg/XenResetVector/XenResetVector.inf b/OvmfPkg/XenResetVector/XenResetVector.inf
> index 5c05f02285..ec98c17876 100644
> --- a/OvmfPkg/XenResetVector/XenResetVector.inf
> +++ b/OvmfPkg/XenResetVector/XenResetVector.inf
> @@ -41,3 +41,6 @@ [BuildOptions]
> [Pcd]
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> +
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> index c4802bf4d1..4e55b0ac1f 100644
> --- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> @@ -22,6 +22,10 @@ xenPVHMain:
> ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> mov esp, eax
>
> + ;; Store "Start of day" struct pointer for later use
> + mov dword[PVH_SPACE (0)], ebx
> + mov dword[PVH_SPACE (4)], 'XPVH'
> +
> cli
>
> mov ebx, ADDR_OF(gdtr)
> diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> index d5a791c139..50cb81fcd1 100644
> --- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
> +++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> @@ -41,6 +41,8 @@
>
> %include "CommonMacros.inc"
>
> +%define PVH_SPACE(Offset) (FixedPcdGet32 (PcdXenStartOfDayStructPtr) + (Offset))
> +
> %include "PostCodes.inc"
>
> %ifdef DEBUG_PORT80
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 08/31] OvmfPkg/XenResetVector: Allow to jumpstart from either hvmloader or PVH
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This patch allows the ResetVector to be run indenpendently from build
time addresses.
The goal of the patch is to avoid having to create RAM just below 4G
when creating a Xen PVH guest while been compatible with the way
hvmloader currently load OVMF, just below 4G.
Only the new PVH entry point will do the calculation.
The ResetVector will figure out its current running address by creating
a temporary stack, make a call and calculate the difference between the
build time address and the address at run time.
This patch copies and make the necessary modification to some other asm
files:
- copy of UefiCpuPkg/.../Flat32ToFlat64.asm:
Allow Transition32FlatTo64Flat to been runnned from anywhere in memory
_ copy of UefiCpuPkg/../SearchForBfvBase.asm:
Add a extra parameter to indicate where to start the search for the
boot firmware volume.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm | 3 ++
{UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia32/Flat32ToFlat64.asm | 25 ++++++++++++++--
{UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia32/SearchForBfvBase.asm | 19 +++++++++----
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 30 ++++++++++++++++++--
4 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
index e22e92c8a6..eebced6ced 100644
--- a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
+++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
@@ -61,6 +61,9 @@ jumpTo32BitAndLandHere:
mov gs, ax
mov ss, ax
+ ; parameter for Flat32SearchForBfvBase
+ xor eax, eax ; Start searching from top of 4GB for BfvBase
+
OneTimeCallRet TransitionFromReal16To32BitFlat
ALIGN 2
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
similarity index 69%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm
copy to OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
index 5b6b375330..ca03ea43e0 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm
+++ b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
@@ -3,6 +3,8 @@
; Transition from 32 bit flat protected mode into 64 bit flat protected mode
;
; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
@@ -16,7 +18,7 @@
BITS 32
;
-; Modified: EAX
+; Modified: EAX, EBX, ECX, EDX, ESP
;
Transition32FlatTo64Flat:
@@ -35,10 +37,29 @@ Transition32FlatTo64Flat:
bts eax, 31 ; set PG
mov cr0, eax ; enable paging
- jmp LINEAR_CODE64_SEL:ADDR_OF(jumpTo64BitAndLandHere)
+ ; backup ESP
+ mov ebx, esp
+
+ ;; recalculate delta
+ mov esp, PVH_SPACE(16)
+ call .delta
+.delta:
+ pop edx
+ sub edx, ADDR_OF(.delta)
+
+ ; push return addr and seg to the stack, then return far
+ push dword LINEAR_CODE64_SEL
+ mov eax, ADDR_OF(jumpTo64BitAndLandHere)
+ add eax, edx ; add delta
+ push eax
+ retf
+
BITS 64
jumpTo64BitAndLandHere:
+ ; restore ESP
+ mov esp, ebx
+
debugShowPostCode POSTCODE_64BIT_MODE
OneTimeCallRet Transition32FlatTo64Flat
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
similarity index 83%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm
copy to OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
index d0c2d8c39c..0519e05601 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm
+++ b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
@@ -3,6 +3,8 @@
; Search for the Boot Firmware Volume (BFV) base address
;
; Copyright (c) 2008 - 2009, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
@@ -23,22 +25,26 @@
BITS 32
;
-; Modified: EAX, EBX
+; Modified: EAX, EBX, ECX
; Preserved: EDI, ESP
;
+; @param[in] EAX Start search from here
; @param[out] EBP Address of Boot Firmware Volume (BFV)
;
Flat32SearchForBfvBase:
- xor eax, eax
+ mov ecx, eax
searchingForBfvHeaderLoop:
;
- ; We check for a firmware volume at every 4KB address in the top 16MB
- ; just below 4GB. (Addresses at 0xffHHH000 where H is any hex digit.)
+ ; We check for a firmware volume at every 4KB address in the 16MB
+ ; just below where we started, ECX.
;
sub eax, 0x1000
- cmp eax, 0xff000000
- jb searchedForBfvHeaderButNotFound
+ mov ebx, ecx
+ sub ebx, eax
+ cmp ebx, 0x01000000
+ ; if ECX-EAX > 16MB; jump notfound
+ ja searchedForBfvHeaderButNotFound
;
; Check FFS GUID
@@ -59,6 +65,7 @@ searchingForBfvHeaderLoop:
jne searchingForBfvHeaderLoop
mov ebx, eax
add ebx, dword [eax + 0x20]
+ cmp ebx, ecx
jnz searchingForBfvHeaderLoop
jmp searchedForBfvHeaderAndItWasFound
diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
index 4e55b0ac1f..612b2e9c44 100644
--- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -19,22 +19,39 @@ BITS 32
xenPVHMain:
mov di, 'BP'
- ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
- mov esp, eax
+ ; EBP - Initial value of the EAX register (BIST: Built-in Self Test)
+ mov ebp, eax
;; Store "Start of day" struct pointer for later use
mov dword[PVH_SPACE (0)], ebx
mov dword[PVH_SPACE (4)], 'XPVH'
+ ;; calculate delta between build-addr and run position
+ mov esp, PVH_SPACE(16) ; create a temporary stack
+ call .delta
+.delta:
+ pop edx ; get addr of .delta
+ sub edx, ADDR_OF(.delta) ; calculate delta
+
cli
+ ;; Find address of GDT and gdtr and fix the later
mov ebx, ADDR_OF(gdtr)
+ add ebx, edx ; add delta gdtr
+ mov eax, ADDR_OF(GDT_BASE)
+ add eax, edx ; add delta to GDT_BASE
+ mov dword[ebx + 2], eax ; fix GDT_BASE addr in gdtr
lgdt [ebx]
mov eax, SEC_DEFAULT_CR0
mov cr0, eax
- jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
+ ;; push return addr to the stack, then return far
+ push dword LINEAR_CODE_SEL ; segment to select
+ mov eax, ADDR_OF(.jmpToNewCodeSeg) ; return addr
+ add eax, edx ; add delta to return addr
+ push eax
+ retf
.jmpToNewCodeSeg:
mov eax, SEC_DEFAULT_CR4
@@ -47,5 +64,12 @@ xenPVHMain:
mov gs, ax
mov ss, ax
+ ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
+ mov esp, ebp
+
+ ; parameter for Flat32SearchForBfvBase
+ mov eax, ADDR_OF(fourGigabytes)
+ add eax, edx ; add delta
+
; return to the Main16
OneTimeCallRet TransitionFromReal16To32BitFlat
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 08/31] OvmfPkg/XenResetVector: Allow to jumpstart from either hvmloader or PVH
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This patch allows the ResetVector to be run indenpendently from build
time addresses.
The goal of the patch is to avoid having to create RAM just below 4G
when creating a Xen PVH guest while been compatible with the way
hvmloader currently load OVMF, just below 4G.
Only the new PVH entry point will do the calculation.
The ResetVector will figure out its current running address by creating
a temporary stack, make a call and calculate the difference between the
build time address and the address at run time.
This patch copies and make the necessary modification to some other asm
files:
- copy of UefiCpuPkg/.../Flat32ToFlat64.asm:
Allow Transition32FlatTo64Flat to been runnned from anywhere in memory
_ copy of UefiCpuPkg/../SearchForBfvBase.asm:
Add a extra parameter to indicate where to start the search for the
boot firmware volume.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm | 3 ++
{UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia32/Flat32ToFlat64.asm | 25 ++++++++++++++--
{UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia32/SearchForBfvBase.asm | 19 +++++++++----
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 30 ++++++++++++++++++--
4 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
index e22e92c8a6..eebced6ced 100644
--- a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
+++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
@@ -61,6 +61,9 @@ jumpTo32BitAndLandHere:
mov gs, ax
mov ss, ax
+ ; parameter for Flat32SearchForBfvBase
+ xor eax, eax ; Start searching from top of 4GB for BfvBase
+
OneTimeCallRet TransitionFromReal16To32BitFlat
ALIGN 2
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
similarity index 69%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm
copy to OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
index 5b6b375330..ca03ea43e0 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm
+++ b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
@@ -3,6 +3,8 @@
; Transition from 32 bit flat protected mode into 64 bit flat protected mode
;
; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
@@ -16,7 +18,7 @@
BITS 32
;
-; Modified: EAX
+; Modified: EAX, EBX, ECX, EDX, ESP
;
Transition32FlatTo64Flat:
@@ -35,10 +37,29 @@ Transition32FlatTo64Flat:
bts eax, 31 ; set PG
mov cr0, eax ; enable paging
- jmp LINEAR_CODE64_SEL:ADDR_OF(jumpTo64BitAndLandHere)
+ ; backup ESP
+ mov ebx, esp
+
+ ;; recalculate delta
+ mov esp, PVH_SPACE(16)
+ call .delta
+.delta:
+ pop edx
+ sub edx, ADDR_OF(.delta)
+
+ ; push return addr and seg to the stack, then return far
+ push dword LINEAR_CODE64_SEL
+ mov eax, ADDR_OF(jumpTo64BitAndLandHere)
+ add eax, edx ; add delta
+ push eax
+ retf
+
BITS 64
jumpTo64BitAndLandHere:
+ ; restore ESP
+ mov esp, ebx
+
debugShowPostCode POSTCODE_64BIT_MODE
OneTimeCallRet Transition32FlatTo64Flat
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
similarity index 83%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm
copy to OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
index d0c2d8c39c..0519e05601 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm
+++ b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
@@ -3,6 +3,8 @@
; Search for the Boot Firmware Volume (BFV) base address
;
; Copyright (c) 2008 - 2009, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
; This program and the accompanying materials
; are licensed and made available under the terms and conditions of the BSD License
; which accompanies this distribution. The full text of the license may be found at
@@ -23,22 +25,26 @@
BITS 32
;
-; Modified: EAX, EBX
+; Modified: EAX, EBX, ECX
; Preserved: EDI, ESP
;
+; @param[in] EAX Start search from here
; @param[out] EBP Address of Boot Firmware Volume (BFV)
;
Flat32SearchForBfvBase:
- xor eax, eax
+ mov ecx, eax
searchingForBfvHeaderLoop:
;
- ; We check for a firmware volume at every 4KB address in the top 16MB
- ; just below 4GB. (Addresses at 0xffHHH000 where H is any hex digit.)
+ ; We check for a firmware volume at every 4KB address in the 16MB
+ ; just below where we started, ECX.
;
sub eax, 0x1000
- cmp eax, 0xff000000
- jb searchedForBfvHeaderButNotFound
+ mov ebx, ecx
+ sub ebx, eax
+ cmp ebx, 0x01000000
+ ; if ECX-EAX > 16MB; jump notfound
+ ja searchedForBfvHeaderButNotFound
;
; Check FFS GUID
@@ -59,6 +65,7 @@ searchingForBfvHeaderLoop:
jne searchingForBfvHeaderLoop
mov ebx, eax
add ebx, dword [eax + 0x20]
+ cmp ebx, ecx
jnz searchingForBfvHeaderLoop
jmp searchedForBfvHeaderAndItWasFound
diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
index 4e55b0ac1f..612b2e9c44 100644
--- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -19,22 +19,39 @@ BITS 32
xenPVHMain:
mov di, 'BP'
- ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
- mov esp, eax
+ ; EBP - Initial value of the EAX register (BIST: Built-in Self Test)
+ mov ebp, eax
;; Store "Start of day" struct pointer for later use
mov dword[PVH_SPACE (0)], ebx
mov dword[PVH_SPACE (4)], 'XPVH'
+ ;; calculate delta between build-addr and run position
+ mov esp, PVH_SPACE(16) ; create a temporary stack
+ call .delta
+.delta:
+ pop edx ; get addr of .delta
+ sub edx, ADDR_OF(.delta) ; calculate delta
+
cli
+ ;; Find address of GDT and gdtr and fix the later
mov ebx, ADDR_OF(gdtr)
+ add ebx, edx ; add delta gdtr
+ mov eax, ADDR_OF(GDT_BASE)
+ add eax, edx ; add delta to GDT_BASE
+ mov dword[ebx + 2], eax ; fix GDT_BASE addr in gdtr
lgdt [ebx]
mov eax, SEC_DEFAULT_CR0
mov cr0, eax
- jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
+ ;; push return addr to the stack, then return far
+ push dword LINEAR_CODE_SEL ; segment to select
+ mov eax, ADDR_OF(.jmpToNewCodeSeg) ; return addr
+ add eax, edx ; add delta to return addr
+ push eax
+ retf
.jmpToNewCodeSeg:
mov eax, SEC_DEFAULT_CR4
@@ -47,5 +64,12 @@ xenPVHMain:
mov gs, ax
mov ss, ax
+ ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
+ mov esp, ebp
+
+ ; parameter for Flat32SearchForBfvBase
+ mov eax, ADDR_OF(fourGigabytes)
+ add eax, edx ; add delta
+
; return to the Main16
OneTimeCallRet TransitionFromReal16To32BitFlat
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 08/31] OvmfPkg/XenResetVector: Allow to jumpstart from either hvmloader or PVH
@ 2019-04-11 11:19 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:19 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This patch allows the ResetVector to be run indenpendently from build
> time addresses.
>
> The goal of the patch is to avoid having to create RAM just below 4G
> when creating a Xen PVH guest while been compatible with the way
(1) s/been/being/
> hvmloader currently load OVMF, just below 4G.
>
> Only the new PVH entry point will do the calculation.
>
> The ResetVector will figure out its current running address by creating
> a temporary stack, make a call and calculate the difference between the
> build time address and the address at run time.
>
> This patch copies and make the necessary modification to some other asm
> files:
> - copy of UefiCpuPkg/.../Flat32ToFlat64.asm:
> Allow Transition32FlatTo64Flat to been runnned from anywhere in memory
(2) s/been runned/be run/
> _ copy of UefiCpuPkg/../SearchForBfvBase.asm:
(3) please replace the underscore (_) with a hyphen (-)
> Add a extra parameter to indicate where to start the search for the
> boot firmware volume.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm | 3 ++
> {UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia32/Flat32ToFlat64.asm | 25 ++++++++++++++--
> {UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia32/SearchForBfvBase.asm | 19 +++++++++----
> OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 30 ++++++++++++++++++--
> 4 files changed, 66 insertions(+), 11 deletions(-)
(4) For the subject line: please drop the word "to".
With those:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
>
> diff --git a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> index e22e92c8a6..eebced6ced 100644
> --- a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> +++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> @@ -61,6 +61,9 @@ jumpTo32BitAndLandHere:
> mov gs, ax
> mov ss, ax
>
> + ; parameter for Flat32SearchForBfvBase
> + xor eax, eax ; Start searching from top of 4GB for BfvBase
> +
> OneTimeCallRet TransitionFromReal16To32BitFlat
>
> ALIGN 2
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
> similarity index 69%
> copy from UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm
> copy to OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
> index 5b6b375330..ca03ea43e0 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm
> +++ b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
> @@ -3,6 +3,8 @@
> ; Transition from 32 bit flat protected mode into 64 bit flat protected mode
> ;
> ; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
> @@ -16,7 +18,7 @@
> BITS 32
>
> ;
> -; Modified: EAX
> +; Modified: EAX, EBX, ECX, EDX, ESP
> ;
> Transition32FlatTo64Flat:
>
> @@ -35,10 +37,29 @@ Transition32FlatTo64Flat:
> bts eax, 31 ; set PG
> mov cr0, eax ; enable paging
>
> - jmp LINEAR_CODE64_SEL:ADDR_OF(jumpTo64BitAndLandHere)
> + ; backup ESP
> + mov ebx, esp
> +
> + ;; recalculate delta
> + mov esp, PVH_SPACE(16)
> + call .delta
> +.delta:
> + pop edx
> + sub edx, ADDR_OF(.delta)
> +
> + ; push return addr and seg to the stack, then return far
> + push dword LINEAR_CODE64_SEL
> + mov eax, ADDR_OF(jumpTo64BitAndLandHere)
> + add eax, edx ; add delta
> + push eax
> + retf
> +
> BITS 64
> jumpTo64BitAndLandHere:
>
> + ; restore ESP
> + mov esp, ebx
> +
> debugShowPostCode POSTCODE_64BIT_MODE
>
> OneTimeCallRet Transition32FlatTo64Flat
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
> similarity index 83%
> copy from UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm
> copy to OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
> index d0c2d8c39c..0519e05601 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm
> +++ b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
> @@ -3,6 +3,8 @@
> ; Search for the Boot Firmware Volume (BFV) base address
> ;
> ; Copyright (c) 2008 - 2009, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
> @@ -23,22 +25,26 @@
> BITS 32
>
> ;
> -; Modified: EAX, EBX
> +; Modified: EAX, EBX, ECX
> ; Preserved: EDI, ESP
> ;
> +; @param[in] EAX Start search from here
> ; @param[out] EBP Address of Boot Firmware Volume (BFV)
> ;
> Flat32SearchForBfvBase:
>
> - xor eax, eax
> + mov ecx, eax
> searchingForBfvHeaderLoop:
> ;
> - ; We check for a firmware volume at every 4KB address in the top 16MB
> - ; just below 4GB. (Addresses at 0xffHHH000 where H is any hex digit.)
> + ; We check for a firmware volume at every 4KB address in the 16MB
> + ; just below where we started, ECX.
> ;
> sub eax, 0x1000
> - cmp eax, 0xff000000
> - jb searchedForBfvHeaderButNotFound
> + mov ebx, ecx
> + sub ebx, eax
> + cmp ebx, 0x01000000
> + ; if ECX-EAX > 16MB; jump notfound
> + ja searchedForBfvHeaderButNotFound
>
> ;
> ; Check FFS GUID
> @@ -59,6 +65,7 @@ searchingForBfvHeaderLoop:
> jne searchingForBfvHeaderLoop
> mov ebx, eax
> add ebx, dword [eax + 0x20]
> + cmp ebx, ecx
> jnz searchingForBfvHeaderLoop
>
> jmp searchedForBfvHeaderAndItWasFound
> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> index 4e55b0ac1f..612b2e9c44 100644
> --- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> @@ -19,22 +19,39 @@ BITS 32
> xenPVHMain:
> mov di, 'BP'
>
> - ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> - mov esp, eax
> + ; EBP - Initial value of the EAX register (BIST: Built-in Self Test)
> + mov ebp, eax
>
> ;; Store "Start of day" struct pointer for later use
> mov dword[PVH_SPACE (0)], ebx
> mov dword[PVH_SPACE (4)], 'XPVH'
>
> + ;; calculate delta between build-addr and run position
> + mov esp, PVH_SPACE(16) ; create a temporary stack
> + call .delta
> +.delta:
> + pop edx ; get addr of .delta
> + sub edx, ADDR_OF(.delta) ; calculate delta
> +
> cli
>
> + ;; Find address of GDT and gdtr and fix the later
> mov ebx, ADDR_OF(gdtr)
> + add ebx, edx ; add delta gdtr
> + mov eax, ADDR_OF(GDT_BASE)
> + add eax, edx ; add delta to GDT_BASE
> + mov dword[ebx + 2], eax ; fix GDT_BASE addr in gdtr
> lgdt [ebx]
>
> mov eax, SEC_DEFAULT_CR0
> mov cr0, eax
>
> - jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
> + ;; push return addr to the stack, then return far
> + push dword LINEAR_CODE_SEL ; segment to select
> + mov eax, ADDR_OF(.jmpToNewCodeSeg) ; return addr
> + add eax, edx ; add delta to return addr
> + push eax
> + retf
> .jmpToNewCodeSeg:
>
> mov eax, SEC_DEFAULT_CR4
> @@ -47,5 +64,12 @@ xenPVHMain:
> mov gs, ax
> mov ss, ax
>
> + ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> + mov esp, ebp
> +
> + ; parameter for Flat32SearchForBfvBase
> + mov eax, ADDR_OF(fourGigabytes)
> + add eax, edx ; add delta
> +
> ; return to the Main16
> OneTimeCallRet TransitionFromReal16To32BitFlat
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 08/31] OvmfPkg/XenResetVector: Allow to jumpstart from either hvmloader or PVH
@ 2019-04-11 11:19 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:19 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This patch allows the ResetVector to be run indenpendently from build
> time addresses.
>
> The goal of the patch is to avoid having to create RAM just below 4G
> when creating a Xen PVH guest while been compatible with the way
(1) s/been/being/
> hvmloader currently load OVMF, just below 4G.
>
> Only the new PVH entry point will do the calculation.
>
> The ResetVector will figure out its current running address by creating
> a temporary stack, make a call and calculate the difference between the
> build time address and the address at run time.
>
> This patch copies and make the necessary modification to some other asm
> files:
> - copy of UefiCpuPkg/.../Flat32ToFlat64.asm:
> Allow Transition32FlatTo64Flat to been runnned from anywhere in memory
(2) s/been runned/be run/
> _ copy of UefiCpuPkg/../SearchForBfvBase.asm:
(3) please replace the underscore (_) with a hyphen (-)
> Add a extra parameter to indicate where to start the search for the
> boot firmware volume.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm | 3 ++
> {UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia32/Flat32ToFlat64.asm | 25 ++++++++++++++--
> {UefiCpuPkg/ResetVector/Vtf0 => OvmfPkg/XenResetVector}/Ia32/SearchForBfvBase.asm | 19 +++++++++----
> OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 30 ++++++++++++++++++--
> 4 files changed, 66 insertions(+), 11 deletions(-)
(4) For the subject line: please drop the word "to".
With those:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
>
> diff --git a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> index e22e92c8a6..eebced6ced 100644
> --- a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> +++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> @@ -61,6 +61,9 @@ jumpTo32BitAndLandHere:
> mov gs, ax
> mov ss, ax
>
> + ; parameter for Flat32SearchForBfvBase
> + xor eax, eax ; Start searching from top of 4GB for BfvBase
> +
> OneTimeCallRet TransitionFromReal16To32BitFlat
>
> ALIGN 2
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
> similarity index 69%
> copy from UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm
> copy to OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
> index 5b6b375330..ca03ea43e0 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm
> +++ b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
> @@ -3,6 +3,8 @@
> ; Transition from 32 bit flat protected mode into 64 bit flat protected mode
> ;
> ; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
> @@ -16,7 +18,7 @@
> BITS 32
>
> ;
> -; Modified: EAX
> +; Modified: EAX, EBX, ECX, EDX, ESP
> ;
> Transition32FlatTo64Flat:
>
> @@ -35,10 +37,29 @@ Transition32FlatTo64Flat:
> bts eax, 31 ; set PG
> mov cr0, eax ; enable paging
>
> - jmp LINEAR_CODE64_SEL:ADDR_OF(jumpTo64BitAndLandHere)
> + ; backup ESP
> + mov ebx, esp
> +
> + ;; recalculate delta
> + mov esp, PVH_SPACE(16)
> + call .delta
> +.delta:
> + pop edx
> + sub edx, ADDR_OF(.delta)
> +
> + ; push return addr and seg to the stack, then return far
> + push dword LINEAR_CODE64_SEL
> + mov eax, ADDR_OF(jumpTo64BitAndLandHere)
> + add eax, edx ; add delta
> + push eax
> + retf
> +
> BITS 64
> jumpTo64BitAndLandHere:
>
> + ; restore ESP
> + mov esp, ebx
> +
> debugShowPostCode POSTCODE_64BIT_MODE
>
> OneTimeCallRet Transition32FlatTo64Flat
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
> similarity index 83%
> copy from UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm
> copy to OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
> index d0c2d8c39c..0519e05601 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm
> +++ b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
> @@ -3,6 +3,8 @@
> ; Search for the Boot Firmware Volume (BFV) base address
> ;
> ; Copyright (c) 2008 - 2009, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> ; This program and the accompanying materials
> ; are licensed and made available under the terms and conditions of the BSD License
> ; which accompanies this distribution. The full text of the license may be found at
> @@ -23,22 +25,26 @@
> BITS 32
>
> ;
> -; Modified: EAX, EBX
> +; Modified: EAX, EBX, ECX
> ; Preserved: EDI, ESP
> ;
> +; @param[in] EAX Start search from here
> ; @param[out] EBP Address of Boot Firmware Volume (BFV)
> ;
> Flat32SearchForBfvBase:
>
> - xor eax, eax
> + mov ecx, eax
> searchingForBfvHeaderLoop:
> ;
> - ; We check for a firmware volume at every 4KB address in the top 16MB
> - ; just below 4GB. (Addresses at 0xffHHH000 where H is any hex digit.)
> + ; We check for a firmware volume at every 4KB address in the 16MB
> + ; just below where we started, ECX.
> ;
> sub eax, 0x1000
> - cmp eax, 0xff000000
> - jb searchedForBfvHeaderButNotFound
> + mov ebx, ecx
> + sub ebx, eax
> + cmp ebx, 0x01000000
> + ; if ECX-EAX > 16MB; jump notfound
> + ja searchedForBfvHeaderButNotFound
>
> ;
> ; Check FFS GUID
> @@ -59,6 +65,7 @@ searchingForBfvHeaderLoop:
> jne searchingForBfvHeaderLoop
> mov ebx, eax
> add ebx, dword [eax + 0x20]
> + cmp ebx, ecx
> jnz searchingForBfvHeaderLoop
>
> jmp searchedForBfvHeaderAndItWasFound
> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> index 4e55b0ac1f..612b2e9c44 100644
> --- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> @@ -19,22 +19,39 @@ BITS 32
> xenPVHMain:
> mov di, 'BP'
>
> - ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> - mov esp, eax
> + ; EBP - Initial value of the EAX register (BIST: Built-in Self Test)
> + mov ebp, eax
>
> ;; Store "Start of day" struct pointer for later use
> mov dword[PVH_SPACE (0)], ebx
> mov dword[PVH_SPACE (4)], 'XPVH'
>
> + ;; calculate delta between build-addr and run position
> + mov esp, PVH_SPACE(16) ; create a temporary stack
> + call .delta
> +.delta:
> + pop edx ; get addr of .delta
> + sub edx, ADDR_OF(.delta) ; calculate delta
> +
> cli
>
> + ;; Find address of GDT and gdtr and fix the later
> mov ebx, ADDR_OF(gdtr)
> + add ebx, edx ; add delta gdtr
> + mov eax, ADDR_OF(GDT_BASE)
> + add eax, edx ; add delta to GDT_BASE
> + mov dword[ebx + 2], eax ; fix GDT_BASE addr in gdtr
> lgdt [ebx]
>
> mov eax, SEC_DEFAULT_CR0
> mov cr0, eax
>
> - jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
> + ;; push return addr to the stack, then return far
> + push dword LINEAR_CODE_SEL ; segment to select
> + mov eax, ADDR_OF(.jmpToNewCodeSeg) ; return addr
> + add eax, edx ; add delta to return addr
> + push eax
> + retf
> .jmpToNewCodeSeg:
>
> mov eax, SEC_DEFAULT_CR4
> @@ -47,5 +64,12 @@ xenPVHMain:
> mov gs, ax
> mov ss, ax
>
> + ; ESP - Initial value of the EAX register (BIST: Built-in Self Test)
> + mov esp, ebp
> +
> + ; parameter for Flat32SearchForBfvBase
> + mov eax, ADDR_OF(fourGigabytes)
> + add eax, edx ; add delta
> +
> ; return to the Main16
> OneTimeCallRet TransitionFromReal16To32BitFlat
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 09/31] OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
ACPI Timer does not work in a PVH guest, but local APIC works on both
PVH and HVM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenOvmf.dsc | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 7b8a1fdf6b..cc51bac3be 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -104,7 +104,7 @@ [SkuIds]
################################################################################
[LibraryClasses]
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
@@ -205,7 +205,7 @@ [LibraryClasses.common]
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
[LibraryClasses.common.SEC]
- TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
@@ -284,7 +284,7 @@ [LibraryClasses.common.DXE_CORE]
[LibraryClasses.common.DXE_RUNTIME_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
@@ -301,7 +301,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
[LibraryClasses.common.UEFI_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.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.UEFI_DRIVER]
[LibraryClasses.common.DXE_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
@@ -344,7 +344,7 @@ [LibraryClasses.common.DXE_DRIVER]
[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread
* [Xen-devel] [PATCH v2 09/31] OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
ACPI Timer does not work in a PVH guest, but local APIC works on both
PVH and HVM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenOvmf.dsc | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 7b8a1fdf6b..cc51bac3be 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -104,7 +104,7 @@ [SkuIds]
################################################################################
[LibraryClasses]
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
@@ -205,7 +205,7 @@ [LibraryClasses.common]
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
[LibraryClasses.common.SEC]
- TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
@@ -284,7 +284,7 @@ [LibraryClasses.common.DXE_CORE]
[LibraryClasses.common.DXE_RUNTIME_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
@@ -301,7 +301,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
[LibraryClasses.common.UEFI_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.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.UEFI_DRIVER]
[LibraryClasses.common.DXE_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
@@ -344,7 +344,7 @@ [LibraryClasses.common.DXE_DRIVER]
[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread
* Re: [edk2-devel] [PATCH v2 09/31] OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU
@ 2019-04-11 11:25 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:25 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> ACPI Timer does not work in a PVH guest, but local APIC works on both
> PVH and HVM.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenOvmf.dsc | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 7b8a1fdf6b..cc51bac3be 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -104,7 +104,7 @@ [SkuIds]
> ################################################################################
> [LibraryClasses]
> PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
> PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
> BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
> @@ -205,7 +205,7 @@ [LibraryClasses.common]
> BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
>
> [LibraryClasses.common.SEC]
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
> QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
> !ifdef $(DEBUG_ON_SERIAL_PORT)
> DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> @@ -284,7 +284,7 @@ [LibraryClasses.common.DXE_CORE]
>
> [LibraryClasses.common.DXE_RUNTIME_DRIVER]
> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> @@ -301,7 +301,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>
> [LibraryClasses.common.UEFI_DRIVER]
> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.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.UEFI_DRIVER]
>
> [LibraryClasses.common.DXE_DRIVER]
> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> @@ -344,7 +344,7 @@ [LibraryClasses.common.DXE_DRIVER]
>
> [LibraryClasses.common.UEFI_APPLICATION]
> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
>
(1) I suggest simplifying this patch by:
- deleting all TimerLib resolutions except the one under
[LibraryClasses],
- updating that one (remaining) resolution to SecPeiDxeTimerLibCpu.inf.
With that:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v2 09/31] OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU
@ 2019-04-11 11:25 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:25 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> ACPI Timer does not work in a PVH guest, but local APIC works on both
> PVH and HVM.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenOvmf.dsc | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 7b8a1fdf6b..cc51bac3be 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -104,7 +104,7 @@ [SkuIds]
> ################################################################################
> [LibraryClasses]
> PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
> PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
> BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
> @@ -205,7 +205,7 @@ [LibraryClasses.common]
> BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
>
> [LibraryClasses.common.SEC]
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
> QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
> !ifdef $(DEBUG_ON_SERIAL_PORT)
> DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> @@ -284,7 +284,7 @@ [LibraryClasses.common.DXE_CORE]
>
> [LibraryClasses.common.DXE_RUNTIME_DRIVER]
> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> @@ -301,7 +301,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>
> [LibraryClasses.common.UEFI_DRIVER]
> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.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.UEFI_DRIVER]
>
> [LibraryClasses.common.DXE_DRIVER]
> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> @@ -344,7 +344,7 @@ [LibraryClasses.common.DXE_DRIVER]
>
> [LibraryClasses.common.UEFI_APPLICATION]
> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
>
(1) I suggest simplifying this patch by:
- deleting all TimerLib resolutions except the one under
[LibraryClasses],
- updating that one (remaining) resolution to SecPeiDxeTimerLibCpu.inf.
With that:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [edk2-devel] [PATCH v2 09/31] OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU
@ 2019-04-11 11:33 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:33 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/11/19 13:25, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> ACPI Timer does not work in a PVH guest, but local APIC works on both
>> PVH and HVM.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/XenOvmf.dsc | 12 ++++++------
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
>> index 7b8a1fdf6b..cc51bac3be 100644
>> --- a/OvmfPkg/XenOvmf.dsc
>> +++ b/OvmfPkg/XenOvmf.dsc
>> @@ -104,7 +104,7 @@ [SkuIds]
>> ################################################################################
>> [LibraryClasses]
>> PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>> PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>> BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
>> BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
>> @@ -205,7 +205,7 @@ [LibraryClasses.common]
>> BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
>>
>> [LibraryClasses.common.SEC]
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>> QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
>> !ifdef $(DEBUG_ON_SERIAL_PORT)
>> DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
>> @@ -284,7 +284,7 @@ [LibraryClasses.common.DXE_CORE]
>>
>> [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>> DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
>> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>> @@ -301,7 +301,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>>
>> [LibraryClasses.common.UEFI_DRIVER]
>> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.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.UEFI_DRIVER]
>>
>> [LibraryClasses.common.DXE_DRIVER]
>> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
>> @@ -344,7 +344,7 @@ [LibraryClasses.common.DXE_DRIVER]
>>
>> [LibraryClasses.common.UEFI_APPLICATION]
>> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
>>
>
> (1) I suggest simplifying this patch by:
> - deleting all TimerLib resolutions except the one under
> [LibraryClasses],
> - updating that one (remaining) resolution to SecPeiDxeTimerLibCpu.inf.
>
> With that:
>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
... BTW, this is the first time I hear about
MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
so now I've gone ahead and read the documentation in that INF file.
(It's really nice documentation.)
It says,
# Note: A driver of type DXE_RUNTIME_DRIVER and DXE_SMM_DRIVER can use this TimerLib
# in their initialization without any issues. They only have to be careful in
# the implementation of runtime services and SMI handlers.
# Because CPU Local APIC and ITC could be programmed by OS, it cannot be
# used by SMM drivers and runtime drivers, ACPI timer is recommended for SMM
# drivers and runtime drivers.
Now, Xen doesn't use SMM, and runtime drivers can be penetrated by the
OS anyway, so I'm not concerned about security here. It's just that you
could run into unexpected behavior with runtime drivers, as long as Xen
allows the guest OS to program the hardware like hinted above.
Obviously I haven't checked the runtime drivers included by this new
platform for their consumption of TimerLib. The patch does modify
[LibraryClasses.common.DXE_RUNTIME_DRIVER], so it's likely prudent for
you to build the platform with "--report-file=blah.report", and check
all runtime drivers. For each that consumes TimerLib, I suggest also
checking if they call a TimerLib API at runtime, not just at
initialization.
If it turns out that the above is not only theoretical, I think the
commit message might deserve a note about the fact, but I'm OK to ACK
the patch without such a note too.
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v2 09/31] OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU
@ 2019-04-11 11:33 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:33 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/11/19 13:25, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> ACPI Timer does not work in a PVH guest, but local APIC works on both
>> PVH and HVM.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/XenOvmf.dsc | 12 ++++++------
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
>> index 7b8a1fdf6b..cc51bac3be 100644
>> --- a/OvmfPkg/XenOvmf.dsc
>> +++ b/OvmfPkg/XenOvmf.dsc
>> @@ -104,7 +104,7 @@ [SkuIds]
>> ################################################################################
>> [LibraryClasses]
>> PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>> PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>> BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
>> BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
>> @@ -205,7 +205,7 @@ [LibraryClasses.common]
>> BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
>>
>> [LibraryClasses.common.SEC]
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>> QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
>> !ifdef $(DEBUG_ON_SERIAL_PORT)
>> DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
>> @@ -284,7 +284,7 @@ [LibraryClasses.common.DXE_CORE]
>>
>> [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>> DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
>> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>> @@ -301,7 +301,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>>
>> [LibraryClasses.common.UEFI_DRIVER]
>> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.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.UEFI_DRIVER]
>>
>> [LibraryClasses.common.DXE_DRIVER]
>> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
>> @@ -344,7 +344,7 @@ [LibraryClasses.common.DXE_DRIVER]
>>
>> [LibraryClasses.common.UEFI_APPLICATION]
>> PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>> - TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>> + TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>> HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
>>
>
> (1) I suggest simplifying this patch by:
> - deleting all TimerLib resolutions except the one under
> [LibraryClasses],
> - updating that one (remaining) resolution to SecPeiDxeTimerLibCpu.inf.
>
> With that:
>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
... BTW, this is the first time I hear about
MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
so now I've gone ahead and read the documentation in that INF file.
(It's really nice documentation.)
It says,
# Note: A driver of type DXE_RUNTIME_DRIVER and DXE_SMM_DRIVER can use this TimerLib
# in their initialization without any issues. They only have to be careful in
# the implementation of runtime services and SMI handlers.
# Because CPU Local APIC and ITC could be programmed by OS, it cannot be
# used by SMM drivers and runtime drivers, ACPI timer is recommended for SMM
# drivers and runtime drivers.
Now, Xen doesn't use SMM, and runtime drivers can be penetrated by the
OS anyway, so I'm not concerned about security here. It's just that you
could run into unexpected behavior with runtime drivers, as long as Xen
allows the guest OS to program the hardware like hinted above.
Obviously I haven't checked the runtime drivers included by this new
platform for their consumption of TimerLib. The patch does modify
[LibraryClasses.common.DXE_RUNTIME_DRIVER], so it's likely prudent for
you to build the platform with "--report-file=blah.report", and check
all runtime drivers. For each that consumes TimerLib, I suggest also
checking if they call a TimerLib API at runtime, not just at
initialization.
If it turns out that the above is not only theoretical, I think the
commit message might deserve a note about the fact, but I'm OK to ACK
the patch without such a note too.
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 10/31] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This struct is only useful to retrieve the E820 table. The
mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
retrieve the E820 table.
Also remove the unused pointer from the XenInfo HOB as that information
is only useful in the XenPlatformPei.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/Include/Guid/XenInfo.h | 4 ----
OvmfPkg/PlatformPei/Xen.c | 3 ---
OvmfPkg/XenPlatformPei/Xen.c | 23 ++++++++++++++++++--
3 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
index d512b0b63f..5d4579f244 100644
--- a/OvmfPkg/Include/Guid/XenInfo.h
+++ b/OvmfPkg/Include/Guid/XenInfo.h
@@ -24,10 +24,6 @@ typedef struct {
///
VOID *HyperPages;
///
- /// Location of the hvm_info page.
- ///
- VOID *HvmInfo;
- ///
/// Hypervisor major version.
///
UINT16 VersionMajor;
diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
index ab38f97a67..75181be2fd 100644
--- a/OvmfPkg/PlatformPei/Xen.c
+++ b/OvmfPkg/PlatformPei/Xen.c
@@ -104,9 +104,6 @@ XenConnect (
mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
- /* TBD: Locate hvm_info and reserve it away. */
- mXenInfo.HvmInfo = NULL;
-
BuildGuidDataHob (
&gEfiXenInfoGuid,
&mXenInfo,
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 7c82e5b69b..a866641b67 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -39,6 +39,12 @@ STATIC UINT32 mXenLeaf = 0;
EFI_XEN_INFO mXenInfo;
+//
+// Location of the firmware info struct setup by hvmloader.
+// Only the E820 table is used by OVMF.
+//
+EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
+
/**
Returns E820 map provided by Xen
@@ -84,6 +90,8 @@ XenConnect (
UINT32 TransferReg;
UINT32 TransferPages;
UINT32 XenVersion;
+ EFI_XEN_OVMF_INFO *Info;
+ CHAR8 Sig[sizeof (Info->Signature) + 1];
AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
@@ -103,8 +111,19 @@ XenConnect (
mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
- /* TBD: Locate hvm_info and reserve it away. */
- mXenInfo.HvmInfo = NULL;
+ //
+ // Check if there are information left by hvmloader
+ //
+
+ Info = (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
+ // Copy the signature, and make it null-terminated.
+ AsciiStrnCpyS(Sig, sizeof (Sig),
+ (CHAR8 *) &Info->Signature, sizeof (Info->Signature));
+ if (AsciiStrCmp (Sig, "XenHVMOVMF") == 0) {
+ mXenHvmloaderInfo = Info;
+ } else {
+ mXenHvmloaderInfo = NULL;
+ }
BuildGuidDataHob (
&gEfiXenInfoGuid,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 10/31] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This struct is only useful to retrieve the E820 table. The
mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
retrieve the E820 table.
Also remove the unused pointer from the XenInfo HOB as that information
is only useful in the XenPlatformPei.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/Include/Guid/XenInfo.h | 4 ----
OvmfPkg/PlatformPei/Xen.c | 3 ---
OvmfPkg/XenPlatformPei/Xen.c | 23 ++++++++++++++++++--
3 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
index d512b0b63f..5d4579f244 100644
--- a/OvmfPkg/Include/Guid/XenInfo.h
+++ b/OvmfPkg/Include/Guid/XenInfo.h
@@ -24,10 +24,6 @@ typedef struct {
///
VOID *HyperPages;
///
- /// Location of the hvm_info page.
- ///
- VOID *HvmInfo;
- ///
/// Hypervisor major version.
///
UINT16 VersionMajor;
diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
index ab38f97a67..75181be2fd 100644
--- a/OvmfPkg/PlatformPei/Xen.c
+++ b/OvmfPkg/PlatformPei/Xen.c
@@ -104,9 +104,6 @@ XenConnect (
mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
- /* TBD: Locate hvm_info and reserve it away. */
- mXenInfo.HvmInfo = NULL;
-
BuildGuidDataHob (
&gEfiXenInfoGuid,
&mXenInfo,
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 7c82e5b69b..a866641b67 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -39,6 +39,12 @@ STATIC UINT32 mXenLeaf = 0;
EFI_XEN_INFO mXenInfo;
+//
+// Location of the firmware info struct setup by hvmloader.
+// Only the E820 table is used by OVMF.
+//
+EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
+
/**
Returns E820 map provided by Xen
@@ -84,6 +90,8 @@ XenConnect (
UINT32 TransferReg;
UINT32 TransferPages;
UINT32 XenVersion;
+ EFI_XEN_OVMF_INFO *Info;
+ CHAR8 Sig[sizeof (Info->Signature) + 1];
AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
@@ -103,8 +111,19 @@ XenConnect (
mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
- /* TBD: Locate hvm_info and reserve it away. */
- mXenInfo.HvmInfo = NULL;
+ //
+ // Check if there are information left by hvmloader
+ //
+
+ Info = (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
+ // Copy the signature, and make it null-terminated.
+ AsciiStrnCpyS(Sig, sizeof (Sig),
+ (CHAR8 *) &Info->Signature, sizeof (Info->Signature));
+ if (AsciiStrCmp (Sig, "XenHVMOVMF") == 0) {
+ mXenHvmloaderInfo = Info;
+ } else {
+ mXenHvmloaderInfo = NULL;
+ }
BuildGuidDataHob (
&gEfiXenInfoGuid,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 10/31] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
@ 2019-04-11 11:47 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:47 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This struct is only useful to retrieve the E820 table. The
(1) please replace "this struct" with the name of the struct.
> mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
> retrieve the E820 table.
>
> Also remove the unused pointer from the XenInfo HOB as that information
> is only useful in the XenPlatformPei.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/Include/Guid/XenInfo.h | 4 ----
> OvmfPkg/PlatformPei/Xen.c | 3 ---
> OvmfPkg/XenPlatformPei/Xen.c | 23 ++++++++++++++++++--
> 3 files changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
> index d512b0b63f..5d4579f244 100644
> --- a/OvmfPkg/Include/Guid/XenInfo.h
> +++ b/OvmfPkg/Include/Guid/XenInfo.h
> @@ -24,10 +24,6 @@ typedef struct {
> ///
> VOID *HyperPages;
> ///
> - /// Location of the hvm_info page.
> - ///
> - VOID *HvmInfo;
> - ///
> /// Hypervisor major version.
> ///
> UINT16 VersionMajor;
> diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
> index ab38f97a67..75181be2fd 100644
> --- a/OvmfPkg/PlatformPei/Xen.c
> +++ b/OvmfPkg/PlatformPei/Xen.c
> @@ -104,9 +104,6 @@ XenConnect (
> mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
> mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
>
> - /* TBD: Locate hvm_info and reserve it away. */
> - mXenInfo.HvmInfo = NULL;
> -
> BuildGuidDataHob (
> &gEfiXenInfoGuid,
> &mXenInfo,
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 7c82e5b69b..a866641b67 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -39,6 +39,12 @@ STATIC UINT32 mXenLeaf = 0;
>
> EFI_XEN_INFO mXenInfo;
>
> +//
> +// Location of the firmware info struct setup by hvmloader.
> +// Only the E820 table is used by OVMF.
> +//
> +EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
> +
> /**
> Returns E820 map provided by Xen
>
> @@ -84,6 +90,8 @@ XenConnect (
> UINT32 TransferReg;
> UINT32 TransferPages;
> UINT32 XenVersion;
> + EFI_XEN_OVMF_INFO *Info;
> + CHAR8 Sig[sizeof (Info->Signature) + 1];
>
> AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
> mXenInfo.HyperPages = AllocatePages (TransferPages);
> @@ -103,8 +111,19 @@ XenConnect (
> mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
> mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
>
> - /* TBD: Locate hvm_info and reserve it away. */
> - mXenInfo.HvmInfo = NULL;
> + //
> + // Check if there are information left by hvmloader
> + //
> +
> + Info = (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
> + // Copy the signature, and make it null-terminated.
(2) Please use the following style:
//
// Copy the signature, and make it null-terminated.
//
> + AsciiStrnCpyS(Sig, sizeof (Sig),
> + (CHAR8 *) &Info->Signature, sizeof (Info->Signature));
(3) This should be indented as:
AsciiStrnCpyS (
Sig,
sizeof (Sig),
(CHAR8 *) &Info->Signature,
sizeof (Info->Signature)
);
or:
AsciiStrnCpyS (Sig, sizeof (Sig), (CHAR8 *) &Info->Signature,
sizeof (Info->Signature));
(note the whitespace before the opening paren, after the function
designator)
I'm not checking the correctness of the parameters, for now.
With (1) and (3) addressed:
Acked-by: Laszlo Ersek <lersek@redhat.com>
If you can, please verify the comment style and the indentation style in
the other patches too.
Thanks
Laszlo
> + if (AsciiStrCmp (Sig, "XenHVMOVMF") == 0) {
> + mXenHvmloaderInfo = Info;
> + } else {
> + mXenHvmloaderInfo = NULL;
> + }
>
> BuildGuidDataHob (
> &gEfiXenInfoGuid,
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 10/31] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
@ 2019-04-11 11:47 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:47 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This struct is only useful to retrieve the E820 table. The
(1) please replace "this struct" with the name of the struct.
> mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
> retrieve the E820 table.
>
> Also remove the unused pointer from the XenInfo HOB as that information
> is only useful in the XenPlatformPei.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/Include/Guid/XenInfo.h | 4 ----
> OvmfPkg/PlatformPei/Xen.c | 3 ---
> OvmfPkg/XenPlatformPei/Xen.c | 23 ++++++++++++++++++--
> 3 files changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
> index d512b0b63f..5d4579f244 100644
> --- a/OvmfPkg/Include/Guid/XenInfo.h
> +++ b/OvmfPkg/Include/Guid/XenInfo.h
> @@ -24,10 +24,6 @@ typedef struct {
> ///
> VOID *HyperPages;
> ///
> - /// Location of the hvm_info page.
> - ///
> - VOID *HvmInfo;
> - ///
> /// Hypervisor major version.
> ///
> UINT16 VersionMajor;
> diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
> index ab38f97a67..75181be2fd 100644
> --- a/OvmfPkg/PlatformPei/Xen.c
> +++ b/OvmfPkg/PlatformPei/Xen.c
> @@ -104,9 +104,6 @@ XenConnect (
> mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
> mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
>
> - /* TBD: Locate hvm_info and reserve it away. */
> - mXenInfo.HvmInfo = NULL;
> -
> BuildGuidDataHob (
> &gEfiXenInfoGuid,
> &mXenInfo,
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 7c82e5b69b..a866641b67 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -39,6 +39,12 @@ STATIC UINT32 mXenLeaf = 0;
>
> EFI_XEN_INFO mXenInfo;
>
> +//
> +// Location of the firmware info struct setup by hvmloader.
> +// Only the E820 table is used by OVMF.
> +//
> +EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
> +
> /**
> Returns E820 map provided by Xen
>
> @@ -84,6 +90,8 @@ XenConnect (
> UINT32 TransferReg;
> UINT32 TransferPages;
> UINT32 XenVersion;
> + EFI_XEN_OVMF_INFO *Info;
> + CHAR8 Sig[sizeof (Info->Signature) + 1];
>
> AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
> mXenInfo.HyperPages = AllocatePages (TransferPages);
> @@ -103,8 +111,19 @@ XenConnect (
> mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
> mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
>
> - /* TBD: Locate hvm_info and reserve it away. */
> - mXenInfo.HvmInfo = NULL;
> + //
> + // Check if there are information left by hvmloader
> + //
> +
> + Info = (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
> + // Copy the signature, and make it null-terminated.
(2) Please use the following style:
//
// Copy the signature, and make it null-terminated.
//
> + AsciiStrnCpyS(Sig, sizeof (Sig),
> + (CHAR8 *) &Info->Signature, sizeof (Info->Signature));
(3) This should be indented as:
AsciiStrnCpyS (
Sig,
sizeof (Sig),
(CHAR8 *) &Info->Signature,
sizeof (Info->Signature)
);
or:
AsciiStrnCpyS (Sig, sizeof (Sig), (CHAR8 *) &Info->Signature,
sizeof (Info->Signature));
(note the whitespace before the opening paren, after the function
designator)
I'm not checking the correctness of the parameters, for now.
With (1) and (3) addressed:
Acked-by: Laszlo Ersek <lersek@redhat.com>
If you can, please verify the comment style and the indentation style in
the other patches too.
Thanks
Laszlo
> + if (AsciiStrCmp (Sig, "XenHVMOVMF") == 0) {
> + mXenHvmloaderInfo = Info;
> + } else {
> + mXenHvmloaderInfo = NULL;
> + }
>
> BuildGuidDataHob (
> &gEfiXenInfoGuid,
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 10/31] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
@ 2019-04-11 11:47 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:47 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/11/19 13:47, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> This struct is only useful to retrieve the E820 table. The
>
> (1) please replace "this struct" with the name of the struct.
>
>> mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
>> retrieve the E820 table.
>>
>> Also remove the unused pointer from the XenInfo HOB as that information
>> is only useful in the XenPlatformPei.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/Include/Guid/XenInfo.h | 4 ----
>> OvmfPkg/PlatformPei/Xen.c | 3 ---
>> OvmfPkg/XenPlatformPei/Xen.c | 23 ++++++++++++++++++--
>> 3 files changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
>> index d512b0b63f..5d4579f244 100644
>> --- a/OvmfPkg/Include/Guid/XenInfo.h
>> +++ b/OvmfPkg/Include/Guid/XenInfo.h
>> @@ -24,10 +24,6 @@ typedef struct {
>> ///
>> VOID *HyperPages;
>> ///
>> - /// Location of the hvm_info page.
>> - ///
>> - VOID *HvmInfo;
>> - ///
>> /// Hypervisor major version.
>> ///
>> UINT16 VersionMajor;
>> diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
>> index ab38f97a67..75181be2fd 100644
>> --- a/OvmfPkg/PlatformPei/Xen.c
>> +++ b/OvmfPkg/PlatformPei/Xen.c
>> @@ -104,9 +104,6 @@ XenConnect (
>> mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
>> mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
>>
>> - /* TBD: Locate hvm_info and reserve it away. */
>> - mXenInfo.HvmInfo = NULL;
>> -
>> BuildGuidDataHob (
>> &gEfiXenInfoGuid,
>> &mXenInfo,
>> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
>> index 7c82e5b69b..a866641b67 100644
>> --- a/OvmfPkg/XenPlatformPei/Xen.c
>> +++ b/OvmfPkg/XenPlatformPei/Xen.c
>> @@ -39,6 +39,12 @@ STATIC UINT32 mXenLeaf = 0;
>>
>> EFI_XEN_INFO mXenInfo;
>>
>> +//
>> +// Location of the firmware info struct setup by hvmloader.
>> +// Only the E820 table is used by OVMF.
>> +//
>> +EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
>> +
>> /**
>> Returns E820 map provided by Xen
>>
>> @@ -84,6 +90,8 @@ XenConnect (
>> UINT32 TransferReg;
>> UINT32 TransferPages;
>> UINT32 XenVersion;
>> + EFI_XEN_OVMF_INFO *Info;
>> + CHAR8 Sig[sizeof (Info->Signature) + 1];
>>
>> AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
>> mXenInfo.HyperPages = AllocatePages (TransferPages);
>> @@ -103,8 +111,19 @@ XenConnect (
>> mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
>> mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
>>
>> - /* TBD: Locate hvm_info and reserve it away. */
>> - mXenInfo.HvmInfo = NULL;
>> + //
>> + // Check if there are information left by hvmloader
>> + //
>> +
>> + Info = (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
>> + // Copy the signature, and make it null-terminated.
>
> (2) Please use the following style:
>
> //
> // Copy the signature, and make it null-terminated.
> //
>
>> + AsciiStrnCpyS(Sig, sizeof (Sig),
>> + (CHAR8 *) &Info->Signature, sizeof (Info->Signature));
>
> (3) This should be indented as:
>
> AsciiStrnCpyS (
> Sig,
> sizeof (Sig),
> (CHAR8 *) &Info->Signature,
> sizeof (Info->Signature)
> );
>
> or:
>
> AsciiStrnCpyS (Sig, sizeof (Sig), (CHAR8 *) &Info->Signature,
> sizeof (Info->Signature));
>
> (note the whitespace before the opening paren, after the function
> designator)
>
>
> I'm not checking the correctness of the parameters, for now.
>
> With (1) and (3) addressed:
sigh, I meant "(1) through (3)".
> Acked-by: Laszlo Ersek <lersek@redhat.com>
>
> If you can, please verify the comment style and the indentation style in
> the other patches too.
>
> Thanks
> Laszlo
>
>> + if (AsciiStrCmp (Sig, "XenHVMOVMF") == 0) {
>> + mXenHvmloaderInfo = Info;
>> + } else {
>> + mXenHvmloaderInfo = NULL;
>> + }
>>
>> BuildGuidDataHob (
>> &gEfiXenInfoGuid,
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 10/31] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
@ 2019-04-11 11:47 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:47 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/11/19 13:47, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> This struct is only useful to retrieve the E820 table. The
>
> (1) please replace "this struct" with the name of the struct.
>
>> mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
>> retrieve the E820 table.
>>
>> Also remove the unused pointer from the XenInfo HOB as that information
>> is only useful in the XenPlatformPei.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/Include/Guid/XenInfo.h | 4 ----
>> OvmfPkg/PlatformPei/Xen.c | 3 ---
>> OvmfPkg/XenPlatformPei/Xen.c | 23 ++++++++++++++++++--
>> 3 files changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
>> index d512b0b63f..5d4579f244 100644
>> --- a/OvmfPkg/Include/Guid/XenInfo.h
>> +++ b/OvmfPkg/Include/Guid/XenInfo.h
>> @@ -24,10 +24,6 @@ typedef struct {
>> ///
>> VOID *HyperPages;
>> ///
>> - /// Location of the hvm_info page.
>> - ///
>> - VOID *HvmInfo;
>> - ///
>> /// Hypervisor major version.
>> ///
>> UINT16 VersionMajor;
>> diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
>> index ab38f97a67..75181be2fd 100644
>> --- a/OvmfPkg/PlatformPei/Xen.c
>> +++ b/OvmfPkg/PlatformPei/Xen.c
>> @@ -104,9 +104,6 @@ XenConnect (
>> mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
>> mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
>>
>> - /* TBD: Locate hvm_info and reserve it away. */
>> - mXenInfo.HvmInfo = NULL;
>> -
>> BuildGuidDataHob (
>> &gEfiXenInfoGuid,
>> &mXenInfo,
>> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
>> index 7c82e5b69b..a866641b67 100644
>> --- a/OvmfPkg/XenPlatformPei/Xen.c
>> +++ b/OvmfPkg/XenPlatformPei/Xen.c
>> @@ -39,6 +39,12 @@ STATIC UINT32 mXenLeaf = 0;
>>
>> EFI_XEN_INFO mXenInfo;
>>
>> +//
>> +// Location of the firmware info struct setup by hvmloader.
>> +// Only the E820 table is used by OVMF.
>> +//
>> +EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
>> +
>> /**
>> Returns E820 map provided by Xen
>>
>> @@ -84,6 +90,8 @@ XenConnect (
>> UINT32 TransferReg;
>> UINT32 TransferPages;
>> UINT32 XenVersion;
>> + EFI_XEN_OVMF_INFO *Info;
>> + CHAR8 Sig[sizeof (Info->Signature) + 1];
>>
>> AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
>> mXenInfo.HyperPages = AllocatePages (TransferPages);
>> @@ -103,8 +111,19 @@ XenConnect (
>> mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
>> mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
>>
>> - /* TBD: Locate hvm_info and reserve it away. */
>> - mXenInfo.HvmInfo = NULL;
>> + //
>> + // Check if there are information left by hvmloader
>> + //
>> +
>> + Info = (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
>> + // Copy the signature, and make it null-terminated.
>
> (2) Please use the following style:
>
> //
> // Copy the signature, and make it null-terminated.
> //
>
>> + AsciiStrnCpyS(Sig, sizeof (Sig),
>> + (CHAR8 *) &Info->Signature, sizeof (Info->Signature));
>
> (3) This should be indented as:
>
> AsciiStrnCpyS (
> Sig,
> sizeof (Sig),
> (CHAR8 *) &Info->Signature,
> sizeof (Info->Signature)
> );
>
> or:
>
> AsciiStrnCpyS (Sig, sizeof (Sig), (CHAR8 *) &Info->Signature,
> sizeof (Info->Signature));
>
> (note the whitespace before the opening paren, after the function
> designator)
>
>
> I'm not checking the correctness of the parameters, for now.
>
> With (1) and (3) addressed:
sigh, I meant "(1) through (3)".
> Acked-by: Laszlo Ersek <lersek@redhat.com>
>
> If you can, please verify the comment style and the indentation style in
> the other patches too.
>
> Thanks
> Laszlo
>
>> + if (AsciiStrCmp (Sig, "XenHVMOVMF") == 0) {
>> + mXenHvmloaderInfo = Info;
>> + } else {
>> + mXenHvmloaderInfo = NULL;
>> + }
>>
>> BuildGuidDataHob (
>> &gEfiXenInfoGuid,
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 11/31] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Use the already checked pointer mXenHvmloaderInfo to retrieve the E820
table produced by hvmloader.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenPlatformPei/Xen.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index a866641b67..df906b6be5 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -59,18 +59,18 @@ XenGetE820Map (
UINT32 *Count
)
{
- EFI_XEN_OVMF_INFO *Info =
- (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
+ //
+ // Get E820 produced by hvmloader
+ //
+ if (mXenHvmloaderInfo != NULL) {
+ ASSERT (mXenHvmloaderInfo->E820 < MAX_ADDRESS);
+ *Entries = (EFI_E820_ENTRY64 *)(UINTN) mXenHvmloaderInfo->E820;
+ *Count = mXenHvmloaderInfo->E820EntriesCount;
- if (AsciiStrCmp ((CHAR8 *) Info->Signature, "XenHVMOVMF")) {
- return EFI_NOT_FOUND;
+ return EFI_SUCCESS;
}
- ASSERT (Info->E820 < MAX_ADDRESS);
- *Entries = (EFI_E820_ENTRY64 *)(UINTN) Info->E820;
- *Count = Info->E820EntriesCount;
-
- return EFI_SUCCESS;
+ return EFI_NOT_FOUND;
}
/**
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 11/31] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Use the already checked pointer mXenHvmloaderInfo to retrieve the E820
table produced by hvmloader.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenPlatformPei/Xen.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index a866641b67..df906b6be5 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -59,18 +59,18 @@ XenGetE820Map (
UINT32 *Count
)
{
- EFI_XEN_OVMF_INFO *Info =
- (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
+ //
+ // Get E820 produced by hvmloader
+ //
+ if (mXenHvmloaderInfo != NULL) {
+ ASSERT (mXenHvmloaderInfo->E820 < MAX_ADDRESS);
+ *Entries = (EFI_E820_ENTRY64 *)(UINTN) mXenHvmloaderInfo->E820;
+ *Count = mXenHvmloaderInfo->E820EntriesCount;
- if (AsciiStrCmp ((CHAR8 *) Info->Signature, "XenHVMOVMF")) {
- return EFI_NOT_FOUND;
+ return EFI_SUCCESS;
}
- ASSERT (Info->E820 < MAX_ADDRESS);
- *Entries = (EFI_E820_ENTRY64 *)(UINTN) Info->E820;
- *Count = Info->E820EntriesCount;
-
- return EFI_SUCCESS;
+ return EFI_NOT_FOUND;
}
/**
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 11/31] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820
@ 2019-04-11 11:49 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:49 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Use the already checked pointer mXenHvmloaderInfo to retrieve the E820
> table produced by hvmloader.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenPlatformPei/Xen.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index a866641b67..df906b6be5 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -59,18 +59,18 @@ XenGetE820Map (
> UINT32 *Count
> )
> {
> - EFI_XEN_OVMF_INFO *Info =
> - (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
> + //
> + // Get E820 produced by hvmloader
> + //
> + if (mXenHvmloaderInfo != NULL) {
> + ASSERT (mXenHvmloaderInfo->E820 < MAX_ADDRESS);
> + *Entries = (EFI_E820_ENTRY64 *)(UINTN) mXenHvmloaderInfo->E820;
> + *Count = mXenHvmloaderInfo->E820EntriesCount;
>
> - if (AsciiStrCmp ((CHAR8 *) Info->Signature, "XenHVMOVMF")) {
> - return EFI_NOT_FOUND;
> + return EFI_SUCCESS;
> }
>
> - ASSERT (Info->E820 < MAX_ADDRESS);
> - *Entries = (EFI_E820_ENTRY64 *)(UINTN) Info->E820;
> - *Count = Info->E820EntriesCount;
> -
> - return EFI_SUCCESS;
> + return EFI_NOT_FOUND;
> }
>
> /**
>
Acked-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 11/31] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820
@ 2019-04-11 11:49 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:49 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Use the already checked pointer mXenHvmloaderInfo to retrieve the E820
> table produced by hvmloader.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenPlatformPei/Xen.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index a866641b67..df906b6be5 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -59,18 +59,18 @@ XenGetE820Map (
> UINT32 *Count
> )
> {
> - EFI_XEN_OVMF_INFO *Info =
> - (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
> + //
> + // Get E820 produced by hvmloader
> + //
> + if (mXenHvmloaderInfo != NULL) {
> + ASSERT (mXenHvmloaderInfo->E820 < MAX_ADDRESS);
> + *Entries = (EFI_E820_ENTRY64 *)(UINTN) mXenHvmloaderInfo->E820;
> + *Count = mXenHvmloaderInfo->E820EntriesCount;
>
> - if (AsciiStrCmp ((CHAR8 *) Info->Signature, "XenHVMOVMF")) {
> - return EFI_NOT_FOUND;
> + return EFI_SUCCESS;
> }
>
> - ASSERT (Info->E820 < MAX_ADDRESS);
> - *Entries = (EFI_E820_ENTRY64 *)(UINTN) Info->E820;
> - *Count = Info->E820EntriesCount;
> -
> - return EFI_SUCCESS;
> + return EFI_NOT_FOUND;
> }
>
> /**
>
Acked-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 12/31] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Check if there's a start of the day struct provided to PVH guest, save
the ACPI RSDP address for later.
This patch import import arch-x86/hvm/start_info.h from xen.git.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 3 +
OvmfPkg/Include/Guid/XenInfo.h | 4 +
OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h | 159 ++++++++++++++++++++
OvmfPkg/XenPlatformPei/Xen.c | 26 ++++
4 files changed, 192 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index c8d25c115f..1870e39208 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -91,6 +91,9 @@ [Pcd]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
+
[FixedPcd]
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
index 5d4579f244..d9c09080bb 100644
--- a/OvmfPkg/Include/Guid/XenInfo.h
+++ b/OvmfPkg/Include/Guid/XenInfo.h
@@ -31,6 +31,10 @@ typedef struct {
/// Hypervisor minor version.
///
UINT16 VersionMinor;
+ ///
+ /// Pointer to the RSDP found in the hvm_start_info provided to a PVH guest
+ ///
+ VOID *RsdpPvh;
} EFI_XEN_INFO;
extern EFI_GUID gEfiXenInfoGuid;
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
new file mode 100644
index 0000000000..71bff7dc37
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
@@ -0,0 +1,159 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2016, Citrix Systems, Inc.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+
+/*
+ * Start of day structure passed to PVH guests and to HVM guests in %ebx.
+ *
+ * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
+ * of the address fields should be treated as not present.
+ *
+ * 0 +----------------+
+ * | magic | Contains the magic value XEN_HVM_START_MAGIC_VALUE
+ * | | ("xEn3" with the 0x80 bit of the "E" set).
+ * 4 +----------------+
+ * | version | Version of this structure. Current version is 1. New
+ * | | versions are guaranteed to be backwards-compatible.
+ * 8 +----------------+
+ * | flags | SIF_xxx flags.
+ * 12 +----------------+
+ * | nr_modules | Number of modules passed to the kernel.
+ * 16 +----------------+
+ * | modlist_paddr | Physical address of an array of modules
+ * | | (layout of the structure below).
+ * 24 +----------------+
+ * | cmdline_paddr | Physical address of the command line,
+ * | | a zero-terminated ASCII string.
+ * 32 +----------------+
+ * | rsdp_paddr | Physical address of the RSDP ACPI data structure.
+ * 40 +----------------+
+ * | memmap_paddr | Physical address of the (optional) memory map. Only
+ * | | present in version 1 and newer of the structure.
+ * 48 +----------------+
+ * | memmap_entries | Number of entries in the memory map table. Zero
+ * | | if there is no memory map being provided. Only
+ * | | present in version 1 and newer of the structure.
+ * 52 +----------------+
+ * | reserved | Version 1 and newer only.
+ * 56 +----------------+
+ *
+ * The layout of each entry in the module structure is the following:
+ *
+ * 0 +----------------+
+ * | paddr | Physical address of the module.
+ * 8 +----------------+
+ * | size | Size of the module in bytes.
+ * 16 +----------------+
+ * | cmdline_paddr | Physical address of the command line,
+ * | | a zero-terminated ASCII string.
+ * 24 +----------------+
+ * | reserved |
+ * 32 +----------------+
+ *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ * 0 +----------------+
+ * | addr | Base address
+ * 8 +----------------+
+ * | size | Size of mapping in bytes
+ * 16 +----------------+
+ * | type | Type of mapping as defined between the hypervisor
+ * | | and guest. See XEN_HVM_MEMMAP_TYPE_* values below.
+ * 20 +----------------|
+ * | reserved |
+ * 24 +----------------+
+ *
+ * The address and sizes are always a 64bit little endian unsigned integer.
+ *
+ * NB: Xen on x86 will always try to place all the data below the 4GiB
+ * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0: Initial implementation.
+ *
+ * Version 1: Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ * padding) to the end of the hvm_start_info struct. These new
+ * fields can be used to pass a memory map to the guest. The
+ * memory map is optional and so guests that understand version 1
+ * of the structure must check that memmap_entries is non-zero
+ * before trying to read the memory map.
+ */
+#define XEN_HVM_START_MAGIC_VALUE 0x336ec578
+
+/*
+ * The values used in the type field of the memory map table entries are
+ * defined below and match the Address Range Types as defined in the "System
+ * Address Map Interfaces" section of the ACPI Specification. Please refer to
+ * section 15 in version 6.2 of the ACPI spec: http://uefi.org/specifications
+ */
+#define XEN_HVM_MEMMAP_TYPE_RAM 1
+#define XEN_HVM_MEMMAP_TYPE_RESERVED 2
+#define XEN_HVM_MEMMAP_TYPE_ACPI 3
+#define XEN_HVM_MEMMAP_TYPE_NVS 4
+#define XEN_HVM_MEMMAP_TYPE_UNUSABLE 5
+#define XEN_HVM_MEMMAP_TYPE_DISABLED 6
+#define XEN_HVM_MEMMAP_TYPE_PMEM 7
+
+/*
+ * C representation of the x86/HVM start info layout.
+ *
+ * The canonical definition of this layout is above, this is just a way to
+ * represent the layout described there using C types.
+ */
+struct hvm_start_info {
+ UINT32 magic; /* Contains the magic value 0x336ec578 */
+ /* ("xEn3" with the 0x80 bit of the "E" set).*/
+ UINT32 version; /* Version of this structure. */
+ UINT32 flags; /* SIF_xxx flags. */
+ UINT32 nr_modules; /* Number of modules passed to the kernel. */
+ UINT64 modlist_paddr; /* Physical address of an array of */
+ /* hvm_modlist_entry. */
+ UINT64 cmdline_paddr; /* Physical address of the command line. */
+ UINT64 rsdp_paddr; /* Physical address of the RSDP ACPI data */
+ /* structure. */
+ /* All following fields only present in version 1 and newer */
+ UINT64 memmap_paddr; /* Physical address of an array of */
+ /* hvm_memmap_table_entry. */
+ UINT32 memmap_entries; /* Number of entries in the memmap table. */
+ /* Value will be zero if there is no memory */
+ /* map being provided. */
+ UINT32 reserved; /* Must be zero. */
+};
+
+struct hvm_modlist_entry {
+ UINT64 paddr; /* Physical address of the module. */
+ UINT64 size; /* Size of the module in bytes. */
+ UINT64 cmdline_paddr; /* Physical address of the command line. */
+ UINT64 reserved;
+};
+
+struct hvm_memmap_table_entry {
+ UINT64 addr; /* Base address of the memory region */
+ UINT64 size; /* Size of the memory region in bytes */
+ UINT32 type; /* Mapping type */
+ UINT32 reserved; /* Must be zero for Version 1. */
+};
+
+#endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index df906b6be5..fb01094ba9 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -31,6 +31,7 @@
#include <IndustryStandard/E820.h>
#include <Library/ResourcePublicationLib.h>
#include <Library/MtrrLib.h>
+#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
#include "Platform.h"
#include "Xen.h"
@@ -92,6 +93,7 @@ XenConnect (
UINT32 XenVersion;
EFI_XEN_OVMF_INFO *Info;
CHAR8 Sig[sizeof (Info->Signature) + 1];
+ UINT32 *PVHResetVectorData;
AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
@@ -125,6 +127,30 @@ XenConnect (
mXenHvmloaderInfo = NULL;
}
+ mXenInfo.RsdpPvh = NULL;
+
+ //
+ // Locate and use information from the start of day structure if we have
+ // booted via the PVH entry point.
+ //
+
+ PVHResetVectorData = (VOID *)(UINTN) PcdGet32(PcdXenStartOfDayStructPtr);
+ //
+ // That magic value is "XPVH", and it is written in
+ // XenResetVector/Ia32/XenPVHMain.asm
+ //
+ if (PVHResetVectorData[1] == 0x48565058) {
+ struct hvm_start_info *HVMStartInfo;
+
+ HVMStartInfo = (VOID *)(UINTN) PVHResetVectorData[0];
+ if (HVMStartInfo->magic == XEN_HVM_START_MAGIC_VALUE) {
+ ASSERT (HVMStartInfo->rsdp_paddr != 0);
+ if (HVMStartInfo->rsdp_paddr != 0) {
+ mXenInfo.RsdpPvh = (VOID *)(UINTN)HVMStartInfo->rsdp_paddr;
+ }
+ }
+ }
+
BuildGuidDataHob (
&gEfiXenInfoGuid,
&mXenInfo,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 12/31] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Check if there's a start of the day struct provided to PVH guest, save
the ACPI RSDP address for later.
This patch import import arch-x86/hvm/start_info.h from xen.git.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 3 +
OvmfPkg/Include/Guid/XenInfo.h | 4 +
OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h | 159 ++++++++++++++++++++
OvmfPkg/XenPlatformPei/Xen.c | 26 ++++
4 files changed, 192 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index c8d25c115f..1870e39208 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -91,6 +91,9 @@ [Pcd]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
+
[FixedPcd]
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
index 5d4579f244..d9c09080bb 100644
--- a/OvmfPkg/Include/Guid/XenInfo.h
+++ b/OvmfPkg/Include/Guid/XenInfo.h
@@ -31,6 +31,10 @@ typedef struct {
/// Hypervisor minor version.
///
UINT16 VersionMinor;
+ ///
+ /// Pointer to the RSDP found in the hvm_start_info provided to a PVH guest
+ ///
+ VOID *RsdpPvh;
} EFI_XEN_INFO;
extern EFI_GUID gEfiXenInfoGuid;
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
new file mode 100644
index 0000000000..71bff7dc37
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
@@ -0,0 +1,159 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2016, Citrix Systems, Inc.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+
+/*
+ * Start of day structure passed to PVH guests and to HVM guests in %ebx.
+ *
+ * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
+ * of the address fields should be treated as not present.
+ *
+ * 0 +----------------+
+ * | magic | Contains the magic value XEN_HVM_START_MAGIC_VALUE
+ * | | ("xEn3" with the 0x80 bit of the "E" set).
+ * 4 +----------------+
+ * | version | Version of this structure. Current version is 1. New
+ * | | versions are guaranteed to be backwards-compatible.
+ * 8 +----------------+
+ * | flags | SIF_xxx flags.
+ * 12 +----------------+
+ * | nr_modules | Number of modules passed to the kernel.
+ * 16 +----------------+
+ * | modlist_paddr | Physical address of an array of modules
+ * | | (layout of the structure below).
+ * 24 +----------------+
+ * | cmdline_paddr | Physical address of the command line,
+ * | | a zero-terminated ASCII string.
+ * 32 +----------------+
+ * | rsdp_paddr | Physical address of the RSDP ACPI data structure.
+ * 40 +----------------+
+ * | memmap_paddr | Physical address of the (optional) memory map. Only
+ * | | present in version 1 and newer of the structure.
+ * 48 +----------------+
+ * | memmap_entries | Number of entries in the memory map table. Zero
+ * | | if there is no memory map being provided. Only
+ * | | present in version 1 and newer of the structure.
+ * 52 +----------------+
+ * | reserved | Version 1 and newer only.
+ * 56 +----------------+
+ *
+ * The layout of each entry in the module structure is the following:
+ *
+ * 0 +----------------+
+ * | paddr | Physical address of the module.
+ * 8 +----------------+
+ * | size | Size of the module in bytes.
+ * 16 +----------------+
+ * | cmdline_paddr | Physical address of the command line,
+ * | | a zero-terminated ASCII string.
+ * 24 +----------------+
+ * | reserved |
+ * 32 +----------------+
+ *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ * 0 +----------------+
+ * | addr | Base address
+ * 8 +----------------+
+ * | size | Size of mapping in bytes
+ * 16 +----------------+
+ * | type | Type of mapping as defined between the hypervisor
+ * | | and guest. See XEN_HVM_MEMMAP_TYPE_* values below.
+ * 20 +----------------|
+ * | reserved |
+ * 24 +----------------+
+ *
+ * The address and sizes are always a 64bit little endian unsigned integer.
+ *
+ * NB: Xen on x86 will always try to place all the data below the 4GiB
+ * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0: Initial implementation.
+ *
+ * Version 1: Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ * padding) to the end of the hvm_start_info struct. These new
+ * fields can be used to pass a memory map to the guest. The
+ * memory map is optional and so guests that understand version 1
+ * of the structure must check that memmap_entries is non-zero
+ * before trying to read the memory map.
+ */
+#define XEN_HVM_START_MAGIC_VALUE 0x336ec578
+
+/*
+ * The values used in the type field of the memory map table entries are
+ * defined below and match the Address Range Types as defined in the "System
+ * Address Map Interfaces" section of the ACPI Specification. Please refer to
+ * section 15 in version 6.2 of the ACPI spec: http://uefi.org/specifications
+ */
+#define XEN_HVM_MEMMAP_TYPE_RAM 1
+#define XEN_HVM_MEMMAP_TYPE_RESERVED 2
+#define XEN_HVM_MEMMAP_TYPE_ACPI 3
+#define XEN_HVM_MEMMAP_TYPE_NVS 4
+#define XEN_HVM_MEMMAP_TYPE_UNUSABLE 5
+#define XEN_HVM_MEMMAP_TYPE_DISABLED 6
+#define XEN_HVM_MEMMAP_TYPE_PMEM 7
+
+/*
+ * C representation of the x86/HVM start info layout.
+ *
+ * The canonical definition of this layout is above, this is just a way to
+ * represent the layout described there using C types.
+ */
+struct hvm_start_info {
+ UINT32 magic; /* Contains the magic value 0x336ec578 */
+ /* ("xEn3" with the 0x80 bit of the "E" set).*/
+ UINT32 version; /* Version of this structure. */
+ UINT32 flags; /* SIF_xxx flags. */
+ UINT32 nr_modules; /* Number of modules passed to the kernel. */
+ UINT64 modlist_paddr; /* Physical address of an array of */
+ /* hvm_modlist_entry. */
+ UINT64 cmdline_paddr; /* Physical address of the command line. */
+ UINT64 rsdp_paddr; /* Physical address of the RSDP ACPI data */
+ /* structure. */
+ /* All following fields only present in version 1 and newer */
+ UINT64 memmap_paddr; /* Physical address of an array of */
+ /* hvm_memmap_table_entry. */
+ UINT32 memmap_entries; /* Number of entries in the memmap table. */
+ /* Value will be zero if there is no memory */
+ /* map being provided. */
+ UINT32 reserved; /* Must be zero. */
+};
+
+struct hvm_modlist_entry {
+ UINT64 paddr; /* Physical address of the module. */
+ UINT64 size; /* Size of the module in bytes. */
+ UINT64 cmdline_paddr; /* Physical address of the command line. */
+ UINT64 reserved;
+};
+
+struct hvm_memmap_table_entry {
+ UINT64 addr; /* Base address of the memory region */
+ UINT64 size; /* Size of the memory region in bytes */
+ UINT32 type; /* Mapping type */
+ UINT32 reserved; /* Must be zero for Version 1. */
+};
+
+#endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index df906b6be5..fb01094ba9 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -31,6 +31,7 @@
#include <IndustryStandard/E820.h>
#include <Library/ResourcePublicationLib.h>
#include <Library/MtrrLib.h>
+#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
#include "Platform.h"
#include "Xen.h"
@@ -92,6 +93,7 @@ XenConnect (
UINT32 XenVersion;
EFI_XEN_OVMF_INFO *Info;
CHAR8 Sig[sizeof (Info->Signature) + 1];
+ UINT32 *PVHResetVectorData;
AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
@@ -125,6 +127,30 @@ XenConnect (
mXenHvmloaderInfo = NULL;
}
+ mXenInfo.RsdpPvh = NULL;
+
+ //
+ // Locate and use information from the start of day structure if we have
+ // booted via the PVH entry point.
+ //
+
+ PVHResetVectorData = (VOID *)(UINTN) PcdGet32(PcdXenStartOfDayStructPtr);
+ //
+ // That magic value is "XPVH", and it is written in
+ // XenResetVector/Ia32/XenPVHMain.asm
+ //
+ if (PVHResetVectorData[1] == 0x48565058) {
+ struct hvm_start_info *HVMStartInfo;
+
+ HVMStartInfo = (VOID *)(UINTN) PVHResetVectorData[0];
+ if (HVMStartInfo->magic == XEN_HVM_START_MAGIC_VALUE) {
+ ASSERT (HVMStartInfo->rsdp_paddr != 0);
+ if (HVMStartInfo->rsdp_paddr != 0) {
+ mXenInfo.RsdpPvh = (VOID *)(UINTN)HVMStartInfo->rsdp_paddr;
+ }
+ }
+ }
+
BuildGuidDataHob (
&gEfiXenInfoGuid,
&mXenInfo,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 12/31] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
@ 2019-04-11 11:58 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:58 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Check if there's a start of the day struct provided to PVH guest, save
> the ACPI RSDP address for later.
>
> This patch import import arch-x86/hvm/start_info.h from xen.git.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 3 +
> OvmfPkg/Include/Guid/XenInfo.h | 4 +
> OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h | 159 ++++++++++++++++++++
> OvmfPkg/XenPlatformPei/Xen.c | 26 ++++
> 4 files changed, 192 insertions(+)
>
> diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> index c8d25c115f..1870e39208 100644
> --- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> +++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> @@ -91,6 +91,9 @@ [Pcd]
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
> gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
>
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
> +
> [FixedPcd]
> gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
>
> diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
> index 5d4579f244..d9c09080bb 100644
> --- a/OvmfPkg/Include/Guid/XenInfo.h
> +++ b/OvmfPkg/Include/Guid/XenInfo.h
> @@ -31,6 +31,10 @@ typedef struct {
> /// Hypervisor minor version.
> ///
> UINT16 VersionMinor;
> + ///
> + /// Pointer to the RSDP found in the hvm_start_info provided to a PVH guest
> + ///
> + VOID *RsdpPvh;
> } EFI_XEN_INFO;
>
> extern EFI_GUID gEfiXenInfoGuid;
> diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
> new file mode 100644
> index 0000000000..71bff7dc37
> --- /dev/null
> +++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
> @@ -0,0 +1,159 @@
> +/*
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
(1) Rather than this license block, please use
SPDX-License-Identifier: MIT
instead -- please refer to
<https://bugzilla.tianocore.org/show_bug.cgi?id=1654>.
> + * Copyright (c) 2016, Citrix Systems, Inc.
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
> +#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
> +
> +/*
> + * Start of day structure passed to PVH guests and to HVM guests in %ebx.
> + *
> + * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
> + * of the address fields should be treated as not present.
> + *
> + * 0 +----------------+
> + * | magic | Contains the magic value XEN_HVM_START_MAGIC_VALUE
> + * | | ("xEn3" with the 0x80 bit of the "E" set).
> + * 4 +----------------+
> + * | version | Version of this structure. Current version is 1. New
> + * | | versions are guaranteed to be backwards-compatible.
> + * 8 +----------------+
> + * | flags | SIF_xxx flags.
> + * 12 +----------------+
> + * | nr_modules | Number of modules passed to the kernel.
> + * 16 +----------------+
> + * | modlist_paddr | Physical address of an array of modules
> + * | | (layout of the structure below).
> + * 24 +----------------+
> + * | cmdline_paddr | Physical address of the command line,
> + * | | a zero-terminated ASCII string.
> + * 32 +----------------+
> + * | rsdp_paddr | Physical address of the RSDP ACPI data structure.
> + * 40 +----------------+
> + * | memmap_paddr | Physical address of the (optional) memory map. Only
> + * | | present in version 1 and newer of the structure.
> + * 48 +----------------+
> + * | memmap_entries | Number of entries in the memory map table. Zero
> + * | | if there is no memory map being provided. Only
> + * | | present in version 1 and newer of the structure.
> + * 52 +----------------+
> + * | reserved | Version 1 and newer only.
> + * 56 +----------------+
> + *
> + * The layout of each entry in the module structure is the following:
> + *
> + * 0 +----------------+
> + * | paddr | Physical address of the module.
> + * 8 +----------------+
> + * | size | Size of the module in bytes.
> + * 16 +----------------+
> + * | cmdline_paddr | Physical address of the command line,
> + * | | a zero-terminated ASCII string.
> + * 24 +----------------+
> + * | reserved |
> + * 32 +----------------+
> + *
> + * The layout of each entry in the memory map table is as follows:
> + *
> + * 0 +----------------+
> + * | addr | Base address
> + * 8 +----------------+
> + * | size | Size of mapping in bytes
> + * 16 +----------------+
> + * | type | Type of mapping as defined between the hypervisor
> + * | | and guest. See XEN_HVM_MEMMAP_TYPE_* values below.
> + * 20 +----------------|
> + * | reserved |
> + * 24 +----------------+
> + *
> + * The address and sizes are always a 64bit little endian unsigned integer.
> + *
> + * NB: Xen on x86 will always try to place all the data below the 4GiB
> + * boundary.
> + *
> + * Version numbers of the hvm_start_info structure have evolved like this:
> + *
> + * Version 0: Initial implementation.
> + *
> + * Version 1: Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
> + * padding) to the end of the hvm_start_info struct. These new
> + * fields can be used to pass a memory map to the guest. The
> + * memory map is optional and so guests that understand version 1
> + * of the structure must check that memmap_entries is non-zero
> + * before trying to read the memory map.
> + */
> +#define XEN_HVM_START_MAGIC_VALUE 0x336ec578
> +
> +/*
> + * The values used in the type field of the memory map table entries are
> + * defined below and match the Address Range Types as defined in the "System
> + * Address Map Interfaces" section of the ACPI Specification. Please refer to
> + * section 15 in version 6.2 of the ACPI spec: http://uefi.org/specifications
> + */
> +#define XEN_HVM_MEMMAP_TYPE_RAM 1
> +#define XEN_HVM_MEMMAP_TYPE_RESERVED 2
> +#define XEN_HVM_MEMMAP_TYPE_ACPI 3
> +#define XEN_HVM_MEMMAP_TYPE_NVS 4
> +#define XEN_HVM_MEMMAP_TYPE_UNUSABLE 5
> +#define XEN_HVM_MEMMAP_TYPE_DISABLED 6
> +#define XEN_HVM_MEMMAP_TYPE_PMEM 7
> +
> +/*
> + * C representation of the x86/HVM start info layout.
> + *
> + * The canonical definition of this layout is above, this is just a way to
> + * represent the layout described there using C types.
> + */
> +struct hvm_start_info {
> + UINT32 magic; /* Contains the magic value 0x336ec578 */
> + /* ("xEn3" with the 0x80 bit of the "E" set).*/
> + UINT32 version; /* Version of this structure. */
> + UINT32 flags; /* SIF_xxx flags. */
> + UINT32 nr_modules; /* Number of modules passed to the kernel. */
> + UINT64 modlist_paddr; /* Physical address of an array of */
> + /* hvm_modlist_entry. */
> + UINT64 cmdline_paddr; /* Physical address of the command line. */
> + UINT64 rsdp_paddr; /* Physical address of the RSDP ACPI data */
> + /* structure. */
> + /* All following fields only present in version 1 and newer */
> + UINT64 memmap_paddr; /* Physical address of an array of */
> + /* hvm_memmap_table_entry. */
> + UINT32 memmap_entries; /* Number of entries in the memmap table. */
> + /* Value will be zero if there is no memory */
> + /* map being provided. */
> + UINT32 reserved; /* Must be zero. */
> +};
> +
> +struct hvm_modlist_entry {
> + UINT64 paddr; /* Physical address of the module. */
> + UINT64 size; /* Size of the module in bytes. */
> + UINT64 cmdline_paddr; /* Physical address of the command line. */
> + UINT64 reserved;
> +};
> +
> +struct hvm_memmap_table_entry {
> + UINT64 addr; /* Base address of the memory region */
> + UINT64 size; /* Size of the memory region in bytes */
> + UINT32 type; /* Mapping type */
> + UINT32 reserved; /* Must be zero for Version 1. */
> +};
> +
> +#endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index df906b6be5..fb01094ba9 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -31,6 +31,7 @@
> #include <IndustryStandard/E820.h>
> #include <Library/ResourcePublicationLib.h>
> #include <Library/MtrrLib.h>
> +#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
>
> #include "Platform.h"
> #include "Xen.h"
> @@ -92,6 +93,7 @@ XenConnect (
> UINT32 XenVersion;
> EFI_XEN_OVMF_INFO *Info;
> CHAR8 Sig[sizeof (Info->Signature) + 1];
> + UINT32 *PVHResetVectorData;
>
> AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
> mXenInfo.HyperPages = AllocatePages (TransferPages);
> @@ -125,6 +127,30 @@ XenConnect (
> mXenHvmloaderInfo = NULL;
> }
>
> + mXenInfo.RsdpPvh = NULL;
> +
> + //
> + // Locate and use information from the start of day structure if we have
> + // booted via the PVH entry point.
> + //
> +
> + PVHResetVectorData = (VOID *)(UINTN) PcdGet32(PcdXenStartOfDayStructPtr);
(2) missing space after PcdGet32
> + //
> + // That magic value is "XPVH", and it is written in
> + // XenResetVector/Ia32/XenPVHMain.asm
> + //
> + if (PVHResetVectorData[1] == 0x48565058) {
(3) If possible, please use the SIGNATURE_32() macro here.
> + struct hvm_start_info *HVMStartInfo;
> +
> + HVMStartInfo = (VOID *)(UINTN) PVHResetVectorData[0];
> + if (HVMStartInfo->magic == XEN_HVM_START_MAGIC_VALUE) {
> + ASSERT (HVMStartInfo->rsdp_paddr != 0);
> + if (HVMStartInfo->rsdp_paddr != 0) {
> + mXenInfo.RsdpPvh = (VOID *)(UINTN)HVMStartInfo->rsdp_paddr;
> + }
> + }
> + }
> +
> BuildGuidDataHob (
> &gEfiXenInfoGuid,
> &mXenInfo,
>
With the above updated
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 12/31] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
@ 2019-04-11 11:58 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 11:58 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Check if there's a start of the day struct provided to PVH guest, save
> the ACPI RSDP address for later.
>
> This patch import import arch-x86/hvm/start_info.h from xen.git.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 3 +
> OvmfPkg/Include/Guid/XenInfo.h | 4 +
> OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h | 159 ++++++++++++++++++++
> OvmfPkg/XenPlatformPei/Xen.c | 26 ++++
> 4 files changed, 192 insertions(+)
>
> diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> index c8d25c115f..1870e39208 100644
> --- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> +++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> @@ -91,6 +91,9 @@ [Pcd]
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
> gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
>
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
> +
> [FixedPcd]
> gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
>
> diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
> index 5d4579f244..d9c09080bb 100644
> --- a/OvmfPkg/Include/Guid/XenInfo.h
> +++ b/OvmfPkg/Include/Guid/XenInfo.h
> @@ -31,6 +31,10 @@ typedef struct {
> /// Hypervisor minor version.
> ///
> UINT16 VersionMinor;
> + ///
> + /// Pointer to the RSDP found in the hvm_start_info provided to a PVH guest
> + ///
> + VOID *RsdpPvh;
> } EFI_XEN_INFO;
>
> extern EFI_GUID gEfiXenInfoGuid;
> diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
> new file mode 100644
> index 0000000000..71bff7dc37
> --- /dev/null
> +++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
> @@ -0,0 +1,159 @@
> +/*
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
(1) Rather than this license block, please use
SPDX-License-Identifier: MIT
instead -- please refer to
<https://bugzilla.tianocore.org/show_bug.cgi?id=1654>.
> + * Copyright (c) 2016, Citrix Systems, Inc.
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
> +#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
> +
> +/*
> + * Start of day structure passed to PVH guests and to HVM guests in %ebx.
> + *
> + * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
> + * of the address fields should be treated as not present.
> + *
> + * 0 +----------------+
> + * | magic | Contains the magic value XEN_HVM_START_MAGIC_VALUE
> + * | | ("xEn3" with the 0x80 bit of the "E" set).
> + * 4 +----------------+
> + * | version | Version of this structure. Current version is 1. New
> + * | | versions are guaranteed to be backwards-compatible.
> + * 8 +----------------+
> + * | flags | SIF_xxx flags.
> + * 12 +----------------+
> + * | nr_modules | Number of modules passed to the kernel.
> + * 16 +----------------+
> + * | modlist_paddr | Physical address of an array of modules
> + * | | (layout of the structure below).
> + * 24 +----------------+
> + * | cmdline_paddr | Physical address of the command line,
> + * | | a zero-terminated ASCII string.
> + * 32 +----------------+
> + * | rsdp_paddr | Physical address of the RSDP ACPI data structure.
> + * 40 +----------------+
> + * | memmap_paddr | Physical address of the (optional) memory map. Only
> + * | | present in version 1 and newer of the structure.
> + * 48 +----------------+
> + * | memmap_entries | Number of entries in the memory map table. Zero
> + * | | if there is no memory map being provided. Only
> + * | | present in version 1 and newer of the structure.
> + * 52 +----------------+
> + * | reserved | Version 1 and newer only.
> + * 56 +----------------+
> + *
> + * The layout of each entry in the module structure is the following:
> + *
> + * 0 +----------------+
> + * | paddr | Physical address of the module.
> + * 8 +----------------+
> + * | size | Size of the module in bytes.
> + * 16 +----------------+
> + * | cmdline_paddr | Physical address of the command line,
> + * | | a zero-terminated ASCII string.
> + * 24 +----------------+
> + * | reserved |
> + * 32 +----------------+
> + *
> + * The layout of each entry in the memory map table is as follows:
> + *
> + * 0 +----------------+
> + * | addr | Base address
> + * 8 +----------------+
> + * | size | Size of mapping in bytes
> + * 16 +----------------+
> + * | type | Type of mapping as defined between the hypervisor
> + * | | and guest. See XEN_HVM_MEMMAP_TYPE_* values below.
> + * 20 +----------------|
> + * | reserved |
> + * 24 +----------------+
> + *
> + * The address and sizes are always a 64bit little endian unsigned integer.
> + *
> + * NB: Xen on x86 will always try to place all the data below the 4GiB
> + * boundary.
> + *
> + * Version numbers of the hvm_start_info structure have evolved like this:
> + *
> + * Version 0: Initial implementation.
> + *
> + * Version 1: Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
> + * padding) to the end of the hvm_start_info struct. These new
> + * fields can be used to pass a memory map to the guest. The
> + * memory map is optional and so guests that understand version 1
> + * of the structure must check that memmap_entries is non-zero
> + * before trying to read the memory map.
> + */
> +#define XEN_HVM_START_MAGIC_VALUE 0x336ec578
> +
> +/*
> + * The values used in the type field of the memory map table entries are
> + * defined below and match the Address Range Types as defined in the "System
> + * Address Map Interfaces" section of the ACPI Specification. Please refer to
> + * section 15 in version 6.2 of the ACPI spec: http://uefi.org/specifications
> + */
> +#define XEN_HVM_MEMMAP_TYPE_RAM 1
> +#define XEN_HVM_MEMMAP_TYPE_RESERVED 2
> +#define XEN_HVM_MEMMAP_TYPE_ACPI 3
> +#define XEN_HVM_MEMMAP_TYPE_NVS 4
> +#define XEN_HVM_MEMMAP_TYPE_UNUSABLE 5
> +#define XEN_HVM_MEMMAP_TYPE_DISABLED 6
> +#define XEN_HVM_MEMMAP_TYPE_PMEM 7
> +
> +/*
> + * C representation of the x86/HVM start info layout.
> + *
> + * The canonical definition of this layout is above, this is just a way to
> + * represent the layout described there using C types.
> + */
> +struct hvm_start_info {
> + UINT32 magic; /* Contains the magic value 0x336ec578 */
> + /* ("xEn3" with the 0x80 bit of the "E" set).*/
> + UINT32 version; /* Version of this structure. */
> + UINT32 flags; /* SIF_xxx flags. */
> + UINT32 nr_modules; /* Number of modules passed to the kernel. */
> + UINT64 modlist_paddr; /* Physical address of an array of */
> + /* hvm_modlist_entry. */
> + UINT64 cmdline_paddr; /* Physical address of the command line. */
> + UINT64 rsdp_paddr; /* Physical address of the RSDP ACPI data */
> + /* structure. */
> + /* All following fields only present in version 1 and newer */
> + UINT64 memmap_paddr; /* Physical address of an array of */
> + /* hvm_memmap_table_entry. */
> + UINT32 memmap_entries; /* Number of entries in the memmap table. */
> + /* Value will be zero if there is no memory */
> + /* map being provided. */
> + UINT32 reserved; /* Must be zero. */
> +};
> +
> +struct hvm_modlist_entry {
> + UINT64 paddr; /* Physical address of the module. */
> + UINT64 size; /* Size of the module in bytes. */
> + UINT64 cmdline_paddr; /* Physical address of the command line. */
> + UINT64 reserved;
> +};
> +
> +struct hvm_memmap_table_entry {
> + UINT64 addr; /* Base address of the memory region */
> + UINT64 size; /* Size of the memory region in bytes */
> + UINT32 type; /* Mapping type */
> + UINT32 reserved; /* Must be zero for Version 1. */
> +};
> +
> +#endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index df906b6be5..fb01094ba9 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -31,6 +31,7 @@
> #include <IndustryStandard/E820.h>
> #include <Library/ResourcePublicationLib.h>
> #include <Library/MtrrLib.h>
> +#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
>
> #include "Platform.h"
> #include "Xen.h"
> @@ -92,6 +93,7 @@ XenConnect (
> UINT32 XenVersion;
> EFI_XEN_OVMF_INFO *Info;
> CHAR8 Sig[sizeof (Info->Signature) + 1];
> + UINT32 *PVHResetVectorData;
>
> AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
> mXenInfo.HyperPages = AllocatePages (TransferPages);
> @@ -125,6 +127,30 @@ XenConnect (
> mXenHvmloaderInfo = NULL;
> }
>
> + mXenInfo.RsdpPvh = NULL;
> +
> + //
> + // Locate and use information from the start of day structure if we have
> + // booted via the PVH entry point.
> + //
> +
> + PVHResetVectorData = (VOID *)(UINTN) PcdGet32(PcdXenStartOfDayStructPtr);
(2) missing space after PcdGet32
> + //
> + // That magic value is "XPVH", and it is written in
> + // XenResetVector/Ia32/XenPVHMain.asm
> + //
> + if (PVHResetVectorData[1] == 0x48565058) {
(3) If possible, please use the SIGNATURE_32() macro here.
> + struct hvm_start_info *HVMStartInfo;
> +
> + HVMStartInfo = (VOID *)(UINTN) PVHResetVectorData[0];
> + if (HVMStartInfo->magic == XEN_HVM_START_MAGIC_VALUE) {
> + ASSERT (HVMStartInfo->rsdp_paddr != 0);
> + if (HVMStartInfo->rsdp_paddr != 0) {
> + mXenInfo.RsdpPvh = (VOID *)(UINTN)HVMStartInfo->rsdp_paddr;
> + }
> + }
> + }
> +
> BuildGuidDataHob (
> &gEfiXenInfoGuid,
> &mXenInfo,
>
With the above updated
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 13/31] OvmfPkg/Library/XenPlatformLib: New library
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
The purpose of XenPlatformPei is to regroup the few functions that are
used in several places to detect if Xen is detected, and to get the
XenInfo HOB.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenOvmf.dsc | 1 +
MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf => OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf | 27 +++----
OvmfPkg/Include/Library/XenPlatformLib.h | 59 +++++++++++++++
OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c | 75 ++++++++++++++++++++
4 files changed, 150 insertions(+), 12 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index cc51bac3be..9529b4834f 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -198,6 +198,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
diff --git a/MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
similarity index 56%
copy from MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
copy to OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
index 4fd4874595..ca078f7263 100644
--- a/MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
+++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
@@ -1,7 +1,10 @@
## @file
-# Null implementation of the SMBUS Library.
+# Get information about Xen
#
-# Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved.<BR>
+# This library simply allow to find out if OVMF is running under Xen and
+# allow to get more information when it is the case.
+#
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -10,26 +13,26 @@
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
#
+#
##
[Defines]
INF_VERSION = 0x00010005
- BASE_NAME = BaseSmbusLibNull
- MODULE_UNI_FILE = BaseSmbusLibNull.uni
- FILE_GUID = E2ECA273-A1C0-407E-9A5C-F10C55142196
+ BASE_NAME = XenPlatformLib
+ FILE_GUID = DB54DBB7-8142-4EE5-9364-78C824B582EB
MODULE_TYPE = BASE
VERSION_STRING = 1.0
- LIBRARY_CLASS = SmbusLib
-
-#
-# VALID_ARCHITECTURES = IA32 X64 EBC
-#
+ LIBRARY_CLASS = XenPlatformLib
[Sources]
- BaseSmbusLibNull.c
+ XenPlatformLib.c
[Packages]
MdePkg/MdePkg.dec
+ OvmfPkg/OvmfPkg.dec
[LibraryClasses]
- DebugLib
+ HobLib
+
+[Guids]
+ gEfiXenInfoGuid
diff --git a/OvmfPkg/Include/Library/XenPlatformLib.h b/OvmfPkg/Include/Library/XenPlatformLib.h
new file mode 100644
index 0000000000..8f57450575
--- /dev/null
+++ b/OvmfPkg/Include/Library/XenPlatformLib.h
@@ -0,0 +1,59 @@
+/** @file
+* Get information about Xen
+*
+* This library simply allow to find out if OVMF is running under Xen and
+* allow to get more information when it is the case.
+*
+* Copyright (c) 2019, Citrix Systems, Inc.
+*
+* This program and the accompanying materials are
+* licensed and made available under the terms and conditions of the BSD License
+* which accompanies this distribution. The full text of the license may be found at
+* http://opensource.org/licenses/bsd-license.php
+*
+* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+*
+**/
+
+#ifndef _XEN_PLATFORM_LIB_H_
+#define _XEN_PLATFORM_LIB_H_
+
+#include <Guid/XenInfo.h>
+
+/**
+ This function detects if OVMF is running on Xen.
+
+ @retval TRUE OVMF is running on Xen
+ @retval FALSE Xen as not been detected
+**/
+BOOLEAN
+EFIAPI
+XenDetected (
+ VOID
+ );
+
+/**
+ This function detect if OVMF have started via the PVH entry point.
+
+ @retval TRUE PVH entry point as been used
+ @retval FALSE OVMF have started via the HVM route
+**/
+BOOLEAN
+EFIAPI
+XenPvhDetected (
+ VOID
+ );
+
+/**
+ This function return a pointer to the XenInfo HOB.
+
+ @return XenInfo pointer or NULL if not available
+**/
+EFI_XEN_INFO *
+EFIAPI
+XenGetInfoHOB (
+ VOID
+ );
+
+#endif
diff --git a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
new file mode 100644
index 0000000000..274ddfc9ad
--- /dev/null
+++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
@@ -0,0 +1,75 @@
+/** @file
+* Get information about Xen
+*
+* This library simply allow to find out if OVMF is running under Xen and
+* allow to get more information when it is the case.
+*
+* Copyright (c) 2019, Citrix Systems, Inc.
+*
+* This program and the accompanying materials are
+* licensed and made available under the terms and conditions of the BSD License
+* which accompanies this distribution. The full text of the license may be found at
+* http://opensource.org/licenses/bsd-license.php
+*
+* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+*
+**/
+
+#include <PiDxe.h>
+#include <Library/HobLib.h>
+#include <Library/XenPlatformLib.h>
+
+/**
+ This function return a pointer to the XenInfo HOB.
+
+ @return XenInfo pointer or NULL if not available
+**/
+EFI_XEN_INFO *
+EFIAPI
+XenGetInfoHOB (
+ VOID
+ )
+{
+ EFI_HOB_GUID_TYPE *GuidHob;
+
+ GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
+ if (GuidHob == NULL) {
+ return NULL;
+ }
+
+ return (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
+}
+
+/**
+ This function detects if OVMF is running on Xen.
+
+ @retval TRUE OVMF is running on Xen
+ @retval FALSE Xen as not been detected
+**/
+BOOLEAN
+EFIAPI
+XenDetected (
+ VOID
+ )
+{
+ return (XenGetInfoHOB () != NULL);
+}
+
+/**
+ This function detect if OVMF have started via the PVH entry point.
+
+ @retval TRUE PVH entry point as been used
+ @retval FALSE OVMF have started via the HVM route
+**/
+BOOLEAN
+EFIAPI
+XenPvhDetected (
+ VOID
+ )
+{
+ EFI_XEN_INFO *XenInfo;
+
+ XenInfo = XenGetInfoHOB ();
+ return (XenInfo != NULL && XenInfo->RsdpPvh != NULL);
+}
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 13/31] OvmfPkg/Library/XenPlatformLib: New library
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
The purpose of XenPlatformPei is to regroup the few functions that are
used in several places to detect if Xen is detected, and to get the
XenInfo HOB.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenOvmf.dsc | 1 +
MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf => OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf | 27 +++----
OvmfPkg/Include/Library/XenPlatformLib.h | 59 +++++++++++++++
OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c | 75 ++++++++++++++++++++
4 files changed, 150 insertions(+), 12 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index cc51bac3be..9529b4834f 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -198,6 +198,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
diff --git a/MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
similarity index 56%
copy from MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
copy to OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
index 4fd4874595..ca078f7263 100644
--- a/MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
+++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
@@ -1,7 +1,10 @@
## @file
-# Null implementation of the SMBUS Library.
+# Get information about Xen
#
-# Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved.<BR>
+# This library simply allow to find out if OVMF is running under Xen and
+# allow to get more information when it is the case.
+#
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -10,26 +13,26 @@
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
#
+#
##
[Defines]
INF_VERSION = 0x00010005
- BASE_NAME = BaseSmbusLibNull
- MODULE_UNI_FILE = BaseSmbusLibNull.uni
- FILE_GUID = E2ECA273-A1C0-407E-9A5C-F10C55142196
+ BASE_NAME = XenPlatformLib
+ FILE_GUID = DB54DBB7-8142-4EE5-9364-78C824B582EB
MODULE_TYPE = BASE
VERSION_STRING = 1.0
- LIBRARY_CLASS = SmbusLib
-
-#
-# VALID_ARCHITECTURES = IA32 X64 EBC
-#
+ LIBRARY_CLASS = XenPlatformLib
[Sources]
- BaseSmbusLibNull.c
+ XenPlatformLib.c
[Packages]
MdePkg/MdePkg.dec
+ OvmfPkg/OvmfPkg.dec
[LibraryClasses]
- DebugLib
+ HobLib
+
+[Guids]
+ gEfiXenInfoGuid
diff --git a/OvmfPkg/Include/Library/XenPlatformLib.h b/OvmfPkg/Include/Library/XenPlatformLib.h
new file mode 100644
index 0000000000..8f57450575
--- /dev/null
+++ b/OvmfPkg/Include/Library/XenPlatformLib.h
@@ -0,0 +1,59 @@
+/** @file
+* Get information about Xen
+*
+* This library simply allow to find out if OVMF is running under Xen and
+* allow to get more information when it is the case.
+*
+* Copyright (c) 2019, Citrix Systems, Inc.
+*
+* This program and the accompanying materials are
+* licensed and made available under the terms and conditions of the BSD License
+* which accompanies this distribution. The full text of the license may be found at
+* http://opensource.org/licenses/bsd-license.php
+*
+* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+*
+**/
+
+#ifndef _XEN_PLATFORM_LIB_H_
+#define _XEN_PLATFORM_LIB_H_
+
+#include <Guid/XenInfo.h>
+
+/**
+ This function detects if OVMF is running on Xen.
+
+ @retval TRUE OVMF is running on Xen
+ @retval FALSE Xen as not been detected
+**/
+BOOLEAN
+EFIAPI
+XenDetected (
+ VOID
+ );
+
+/**
+ This function detect if OVMF have started via the PVH entry point.
+
+ @retval TRUE PVH entry point as been used
+ @retval FALSE OVMF have started via the HVM route
+**/
+BOOLEAN
+EFIAPI
+XenPvhDetected (
+ VOID
+ );
+
+/**
+ This function return a pointer to the XenInfo HOB.
+
+ @return XenInfo pointer or NULL if not available
+**/
+EFI_XEN_INFO *
+EFIAPI
+XenGetInfoHOB (
+ VOID
+ );
+
+#endif
diff --git a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
new file mode 100644
index 0000000000..274ddfc9ad
--- /dev/null
+++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
@@ -0,0 +1,75 @@
+/** @file
+* Get information about Xen
+*
+* This library simply allow to find out if OVMF is running under Xen and
+* allow to get more information when it is the case.
+*
+* Copyright (c) 2019, Citrix Systems, Inc.
+*
+* This program and the accompanying materials are
+* licensed and made available under the terms and conditions of the BSD License
+* which accompanies this distribution. The full text of the license may be found at
+* http://opensource.org/licenses/bsd-license.php
+*
+* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+*
+**/
+
+#include <PiDxe.h>
+#include <Library/HobLib.h>
+#include <Library/XenPlatformLib.h>
+
+/**
+ This function return a pointer to the XenInfo HOB.
+
+ @return XenInfo pointer or NULL if not available
+**/
+EFI_XEN_INFO *
+EFIAPI
+XenGetInfoHOB (
+ VOID
+ )
+{
+ EFI_HOB_GUID_TYPE *GuidHob;
+
+ GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
+ if (GuidHob == NULL) {
+ return NULL;
+ }
+
+ return (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
+}
+
+/**
+ This function detects if OVMF is running on Xen.
+
+ @retval TRUE OVMF is running on Xen
+ @retval FALSE Xen as not been detected
+**/
+BOOLEAN
+EFIAPI
+XenDetected (
+ VOID
+ )
+{
+ return (XenGetInfoHOB () != NULL);
+}
+
+/**
+ This function detect if OVMF have started via the PVH entry point.
+
+ @retval TRUE PVH entry point as been used
+ @retval FALSE OVMF have started via the HVM route
+**/
+BOOLEAN
+EFIAPI
+XenPvhDetected (
+ VOID
+ )
+{
+ EFI_XEN_INFO *XenInfo;
+
+ XenInfo = XenGetInfoHOB ();
+ return (XenInfo != NULL && XenInfo->RsdpPvh != NULL);
+}
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 13/31] OvmfPkg/Library/XenPlatformLib: New library
@ 2019-04-11 12:10 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 12:10 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> The purpose of XenPlatformPei is to regroup the few functions that are
(1) did you mean XenPlatformLib here?
> used in several places to detect if Xen is detected, and to get the
> XenInfo HOB.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenOvmf.dsc | 1 +
> MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf => OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf | 27 +++----
> OvmfPkg/Include/Library/XenPlatformLib.h | 59 +++++++++++++++
> OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c | 75 ++++++++++++++++++++
> 4 files changed, 150 insertions(+), 12 deletions(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index cc51bac3be..9529b4834f 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -198,6 +198,7 @@ [LibraryClasses]
> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>
> Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
>
> diff --git a/MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
> similarity index 56%
> copy from MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> copy to OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
> index 4fd4874595..ca078f7263 100644
> --- a/MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> +++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
obviously this is a false positive for git's "--find-copies-harder", but
I can look at the file in isolation using your git branch...
(3) Please use "SPDX-License-Identifier: BSD-2-Clause-Patent", rather
than the open-coded 2-clause BSDL.
(This applies to other new files in this patch as well.)
[...]
> diff --git a/OvmfPkg/Include/Library/XenPlatformLib.h b/OvmfPkg/Include/Library/XenPlatformLib.h
> new file mode 100644
> index 0000000000..8f57450575
> --- /dev/null
> +++ b/OvmfPkg/Include/Library/XenPlatformLib.h
> @@ -0,0 +1,59 @@
> +/** @file
> +* Get information about Xen
> +*
> +* This library simply allow to find out if OVMF is running under Xen and
> +* allow to get more information when it is the case.
> +*
> +* Copyright (c) 2019, Citrix Systems, Inc.
> +*
> +* This program and the accompanying materials are
> +* licensed and made available under the terms and conditions of the BSD License
> +* which accompanies this distribution. The full text of the license may be found at
> +* http://opensource.org/licenses/bsd-license.php
> +*
> +* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +*
> +**/
> +
> +#ifndef _XEN_PLATFORM_LIB_H_
> +#define _XEN_PLATFORM_LIB_H_
> +
> +#include <Guid/XenInfo.h>
> +
> +/**
> + This function detects if OVMF is running on Xen.
> +
> + @retval TRUE OVMF is running on Xen
> + @retval FALSE Xen as not been detected
(4) "has" not been detected
... same for the function definition as well, in the .c file below.
(5) At the introduction of a new library class, we should update the
[LibraryClasses] section in the "OvmfPkg/OvmfPkg.dec" file. I think you
can add this new class under XenHypercallLib and XenIoMmioLib there.
(To confirm, I'm not speaking about the .dsc file, but the .dec file.)
Thanks
Laszlo
> +**/
> +BOOLEAN
> +EFIAPI
> +XenDetected (
> + VOID
> + );
> +
> +/**
> + This function detect if OVMF have started via the PVH entry point.
> +
> + @retval TRUE PVH entry point as been used
> + @retval FALSE OVMF have started via the HVM route
> +**/
> +BOOLEAN
> +EFIAPI
> +XenPvhDetected (
> + VOID
> + );
> +
> +/**
> + This function return a pointer to the XenInfo HOB.
> +
> + @return XenInfo pointer or NULL if not available
> +**/
> +EFI_XEN_INFO *
> +EFIAPI
> +XenGetInfoHOB (
> + VOID
> + );
> +
> +#endif
> diff --git a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
> new file mode 100644
> index 0000000000..274ddfc9ad
> --- /dev/null
> +++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
> @@ -0,0 +1,75 @@
> +/** @file
> +* Get information about Xen
> +*
> +* This library simply allow to find out if OVMF is running under Xen and
> +* allow to get more information when it is the case.
> +*
> +* Copyright (c) 2019, Citrix Systems, Inc.
> +*
> +* This program and the accompanying materials are
> +* licensed and made available under the terms and conditions of the BSD License
> +* which accompanies this distribution. The full text of the license may be found at
> +* http://opensource.org/licenses/bsd-license.php
> +*
> +* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +*
> +**/
> +
> +#include <PiDxe.h>
> +#include <Library/HobLib.h>
> +#include <Library/XenPlatformLib.h>
> +
> +/**
> + This function return a pointer to the XenInfo HOB.
> +
> + @return XenInfo pointer or NULL if not available
> +**/
> +EFI_XEN_INFO *
> +EFIAPI
> +XenGetInfoHOB (
> + VOID
> + )
> +{
> + EFI_HOB_GUID_TYPE *GuidHob;
> +
> + GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
> + if (GuidHob == NULL) {
> + return NULL;
> + }
> +
> + return (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
> +}
> +
> +/**
> + This function detects if OVMF is running on Xen.
> +
> + @retval TRUE OVMF is running on Xen
> + @retval FALSE Xen as not been detected
> +**/
> +BOOLEAN
> +EFIAPI
> +XenDetected (
> + VOID
> + )
> +{
> + return (XenGetInfoHOB () != NULL);
> +}
> +
> +/**
> + This function detect if OVMF have started via the PVH entry point.
> +
> + @retval TRUE PVH entry point as been used
> + @retval FALSE OVMF have started via the HVM route
> +**/
> +BOOLEAN
> +EFIAPI
> +XenPvhDetected (
> + VOID
> + )
> +{
> + EFI_XEN_INFO *XenInfo;
> +
> + XenInfo = XenGetInfoHOB ();
> + return (XenInfo != NULL && XenInfo->RsdpPvh != NULL);
> +}
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 13/31] OvmfPkg/Library/XenPlatformLib: New library
@ 2019-04-11 12:10 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 12:10 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> The purpose of XenPlatformPei is to regroup the few functions that are
(1) did you mean XenPlatformLib here?
> used in several places to detect if Xen is detected, and to get the
> XenInfo HOB.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenOvmf.dsc | 1 +
> MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf => OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf | 27 +++----
> OvmfPkg/Include/Library/XenPlatformLib.h | 59 +++++++++++++++
> OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c | 75 ++++++++++++++++++++
> 4 files changed, 150 insertions(+), 12 deletions(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index cc51bac3be..9529b4834f 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -198,6 +198,7 @@ [LibraryClasses]
> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>
> Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
>
> diff --git a/MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
> similarity index 56%
> copy from MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> copy to OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
> index 4fd4874595..ca078f7263 100644
> --- a/MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> +++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
obviously this is a false positive for git's "--find-copies-harder", but
I can look at the file in isolation using your git branch...
(3) Please use "SPDX-License-Identifier: BSD-2-Clause-Patent", rather
than the open-coded 2-clause BSDL.
(This applies to other new files in this patch as well.)
[...]
> diff --git a/OvmfPkg/Include/Library/XenPlatformLib.h b/OvmfPkg/Include/Library/XenPlatformLib.h
> new file mode 100644
> index 0000000000..8f57450575
> --- /dev/null
> +++ b/OvmfPkg/Include/Library/XenPlatformLib.h
> @@ -0,0 +1,59 @@
> +/** @file
> +* Get information about Xen
> +*
> +* This library simply allow to find out if OVMF is running under Xen and
> +* allow to get more information when it is the case.
> +*
> +* Copyright (c) 2019, Citrix Systems, Inc.
> +*
> +* This program and the accompanying materials are
> +* licensed and made available under the terms and conditions of the BSD License
> +* which accompanies this distribution. The full text of the license may be found at
> +* http://opensource.org/licenses/bsd-license.php
> +*
> +* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +*
> +**/
> +
> +#ifndef _XEN_PLATFORM_LIB_H_
> +#define _XEN_PLATFORM_LIB_H_
> +
> +#include <Guid/XenInfo.h>
> +
> +/**
> + This function detects if OVMF is running on Xen.
> +
> + @retval TRUE OVMF is running on Xen
> + @retval FALSE Xen as not been detected
(4) "has" not been detected
... same for the function definition as well, in the .c file below.
(5) At the introduction of a new library class, we should update the
[LibraryClasses] section in the "OvmfPkg/OvmfPkg.dec" file. I think you
can add this new class under XenHypercallLib and XenIoMmioLib there.
(To confirm, I'm not speaking about the .dsc file, but the .dec file.)
Thanks
Laszlo
> +**/
> +BOOLEAN
> +EFIAPI
> +XenDetected (
> + VOID
> + );
> +
> +/**
> + This function detect if OVMF have started via the PVH entry point.
> +
> + @retval TRUE PVH entry point as been used
> + @retval FALSE OVMF have started via the HVM route
> +**/
> +BOOLEAN
> +EFIAPI
> +XenPvhDetected (
> + VOID
> + );
> +
> +/**
> + This function return a pointer to the XenInfo HOB.
> +
> + @return XenInfo pointer or NULL if not available
> +**/
> +EFI_XEN_INFO *
> +EFIAPI
> +XenGetInfoHOB (
> + VOID
> + );
> +
> +#endif
> diff --git a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
> new file mode 100644
> index 0000000000..274ddfc9ad
> --- /dev/null
> +++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
> @@ -0,0 +1,75 @@
> +/** @file
> +* Get information about Xen
> +*
> +* This library simply allow to find out if OVMF is running under Xen and
> +* allow to get more information when it is the case.
> +*
> +* Copyright (c) 2019, Citrix Systems, Inc.
> +*
> +* This program and the accompanying materials are
> +* licensed and made available under the terms and conditions of the BSD License
> +* which accompanies this distribution. The full text of the license may be found at
> +* http://opensource.org/licenses/bsd-license.php
> +*
> +* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +*
> +**/
> +
> +#include <PiDxe.h>
> +#include <Library/HobLib.h>
> +#include <Library/XenPlatformLib.h>
> +
> +/**
> + This function return a pointer to the XenInfo HOB.
> +
> + @return XenInfo pointer or NULL if not available
> +**/
> +EFI_XEN_INFO *
> +EFIAPI
> +XenGetInfoHOB (
> + VOID
> + )
> +{
> + EFI_HOB_GUID_TYPE *GuidHob;
> +
> + GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
> + if (GuidHob == NULL) {
> + return NULL;
> + }
> +
> + return (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
> +}
> +
> +/**
> + This function detects if OVMF is running on Xen.
> +
> + @retval TRUE OVMF is running on Xen
> + @retval FALSE Xen as not been detected
> +**/
> +BOOLEAN
> +EFIAPI
> +XenDetected (
> + VOID
> + )
> +{
> + return (XenGetInfoHOB () != NULL);
> +}
> +
> +/**
> + This function detect if OVMF have started via the PVH entry point.
> +
> + @retval TRUE PVH entry point as been used
> + @retval FALSE OVMF have started via the HVM route
> +**/
> +BOOLEAN
> +EFIAPI
> +XenPvhDetected (
> + VOID
> + )
> +{
> + EFI_XEN_INFO *XenInfo;
> +
> + XenInfo = XenGetInfoHOB ();
> + return (XenInfo != NULL && XenInfo->RsdpPvh != NULL);
> +}
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
If the firmware have been started via the PVH entry point, a RSDP
pointer would have been provided. Use it.
Also, use XenDetect() from the new XenPlatformLib.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/OvmfPkgIa32.dsc | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
OvmfPkg/OvmfPkgX64.dsc | 1 +
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 +-
OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h | 6 +--
OvmfPkg/AcpiPlatformDxe/Xen.c | 41 ++++++++------------
6 files changed, 22 insertions(+), 30 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f55ab5a3d2..cab9764cab 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -205,6 +205,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
!if $(TPM2_ENABLE) == TRUE
Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 5c9bdf034e..a156358690 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -210,6 +210,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
!if $(TPM2_ENABLE) == TRUE
Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 2943e9e8af..9d8dc442b4 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -210,6 +210,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
!if $(TPM2_ENABLE) == TRUE
Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 8440e7b343..ca54a3bd9e 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -51,13 +51,13 @@ [LibraryClasses]
DebugLib
UefiBootServicesTableLib
UefiDriverEntryPoint
- HobLib
QemuFwCfgLib
QemuFwCfgS3Lib
MemoryAllocationLib
BaseLib
DxeServicesTableLib
OrderedCollectionLib
+ XenPlatformLib
[Protocols]
gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
index 83b981ee00..85f37128dd 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
@@ -25,6 +25,7 @@
#include <Library/UefiBootServicesTableLib.h>
#include <Library/DebugLib.h>
#include <Library/PcdLib.h>
+#include <Library/XenPlatformLib.h>
#include <IndustryStandard/Acpi.h>
@@ -58,11 +59,6 @@ QemuInstallAcpiTable (
OUT UINTN *TableKey
);
-BOOLEAN
-XenDetected (
- VOID
- );
-
EFI_STATUS
EFIAPI
InstallXenTables (
diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
index 618ac58b42..7e9a7797d7 100644
--- a/OvmfPkg/AcpiPlatformDxe/Xen.c
+++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
@@ -15,8 +15,6 @@
**/
#include "AcpiPlatform.h"
-#include <Library/HobLib.h>
-#include <Guid/XenInfo.h>
#include <Library/BaseLib.h>
#define XEN_ACPI_PHYSICAL_ADDRESS 0x000EA020
@@ -24,28 +22,6 @@
EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr = NULL;
-/**
- This function detects if OVMF is running on Xen.
-
-**/
-BOOLEAN
-XenDetected (
- VOID
- )
-{
- EFI_HOB_GUID_TYPE *GuidHob;
-
- //
- // See if a XenInfo HOB is available
- //
- GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
- if (GuidHob == NULL) {
- return FALSE;
- }
-
- return TRUE;
-}
-
/**
Get the address of Xen ACPI Root System Description Pointer (RSDP)
structure.
@@ -66,10 +42,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, "AcpiPlatformDxe: Use ACPI RSDP table at 0x%08x\n",
+ 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
If the firmware have been started via the PVH entry point, a RSDP
pointer would have been provided. Use it.
Also, use XenDetect() from the new XenPlatformLib.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/OvmfPkgIa32.dsc | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
OvmfPkg/OvmfPkgX64.dsc | 1 +
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 +-
OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h | 6 +--
OvmfPkg/AcpiPlatformDxe/Xen.c | 41 ++++++++------------
6 files changed, 22 insertions(+), 30 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f55ab5a3d2..cab9764cab 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -205,6 +205,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
!if $(TPM2_ENABLE) == TRUE
Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 5c9bdf034e..a156358690 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -210,6 +210,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
!if $(TPM2_ENABLE) == TRUE
Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 2943e9e8af..9d8dc442b4 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -210,6 +210,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
!if $(TPM2_ENABLE) == TRUE
Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 8440e7b343..ca54a3bd9e 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -51,13 +51,13 @@ [LibraryClasses]
DebugLib
UefiBootServicesTableLib
UefiDriverEntryPoint
- HobLib
QemuFwCfgLib
QemuFwCfgS3Lib
MemoryAllocationLib
BaseLib
DxeServicesTableLib
OrderedCollectionLib
+ XenPlatformLib
[Protocols]
gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
index 83b981ee00..85f37128dd 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
@@ -25,6 +25,7 @@
#include <Library/UefiBootServicesTableLib.h>
#include <Library/DebugLib.h>
#include <Library/PcdLib.h>
+#include <Library/XenPlatformLib.h>
#include <IndustryStandard/Acpi.h>
@@ -58,11 +59,6 @@ QemuInstallAcpiTable (
OUT UINTN *TableKey
);
-BOOLEAN
-XenDetected (
- VOID
- );
-
EFI_STATUS
EFIAPI
InstallXenTables (
diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
index 618ac58b42..7e9a7797d7 100644
--- a/OvmfPkg/AcpiPlatformDxe/Xen.c
+++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
@@ -15,8 +15,6 @@
**/
#include "AcpiPlatform.h"
-#include <Library/HobLib.h>
-#include <Guid/XenInfo.h>
#include <Library/BaseLib.h>
#define XEN_ACPI_PHYSICAL_ADDRESS 0x000EA020
@@ -24,28 +22,6 @@
EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr = NULL;
-/**
- This function detects if OVMF is running on Xen.
-
-**/
-BOOLEAN
-XenDetected (
- VOID
- )
-{
- EFI_HOB_GUID_TYPE *GuidHob;
-
- //
- // See if a XenInfo HOB is available
- //
- GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
- if (GuidHob == NULL) {
- return FALSE;
- }
-
- return TRUE;
-}
-
/**
Get the address of Xen ACPI Root System Description Pointer (RSDP)
structure.
@@ -66,10 +42,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, "AcpiPlatformDxe: Use ACPI RSDP table at 0x%08x\n",
+ 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist
@ 2019-04-11 12:20 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 12:20 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> If the firmware have been started via the PVH entry point, a RSDP
> pointer would have been provided. Use it.
>
> Also, use XenDetect() from the new XenPlatformLib.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/OvmfPkgIa32.dsc | 1 +
> OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
> OvmfPkg/OvmfPkgX64.dsc | 1 +
> OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 +-
> OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h | 6 +--
> OvmfPkg/AcpiPlatformDxe/Xen.c | 41 ++++++++------------
> 6 files changed, 22 insertions(+), 30 deletions(-)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index f55ab5a3d2..cab9764cab 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -205,6 +205,7 @@ [LibraryClasses]
> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>
> !if $(TPM2_ENABLE) == TRUE
> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 5c9bdf034e..a156358690 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -210,6 +210,7 @@ [LibraryClasses]
> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>
> !if $(TPM2_ENABLE) == TRUE
> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 2943e9e8af..9d8dc442b4 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -210,6 +210,7 @@ [LibraryClasses]
> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>
> !if $(TPM2_ENABLE) == TRUE
> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> index 8440e7b343..ca54a3bd9e 100644
> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> @@ -51,13 +51,13 @@ [LibraryClasses]
> DebugLib
> UefiBootServicesTableLib
> UefiDriverEntryPoint
> - HobLib
> QemuFwCfgLib
> QemuFwCfgS3Lib
> MemoryAllocationLib
> BaseLib
> DxeServicesTableLib
> OrderedCollectionLib
> + XenPlatformLib
>
> [Protocols]
> gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> index 83b981ee00..85f37128dd 100644
> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> @@ -25,6 +25,7 @@
> #include <Library/UefiBootServicesTableLib.h>
> #include <Library/DebugLib.h>
> #include <Library/PcdLib.h>
> +#include <Library/XenPlatformLib.h>
>
> #include <IndustryStandard/Acpi.h>
>
> @@ -58,11 +59,6 @@ QemuInstallAcpiTable (
> OUT UINTN *TableKey
> );
>
> -BOOLEAN
> -XenDetected (
> - VOID
> - );
> -
> EFI_STATUS
> EFIAPI
> InstallXenTables (
> diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
> index 618ac58b42..7e9a7797d7 100644
> --- a/OvmfPkg/AcpiPlatformDxe/Xen.c
> +++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
> @@ -15,8 +15,6 @@
> **/
>
> #include "AcpiPlatform.h"
> -#include <Library/HobLib.h>
> -#include <Guid/XenInfo.h>
> #include <Library/BaseLib.h>
>
> #define XEN_ACPI_PHYSICAL_ADDRESS 0x000EA020
> @@ -24,28 +22,6 @@
>
> EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr = NULL;
>
> -/**
> - This function detects if OVMF is running on Xen.
> -
> -**/
> -BOOLEAN
> -XenDetected (
> - VOID
> - )
> -{
> - EFI_HOB_GUID_TYPE *GuidHob;
> -
> - //
> - // See if a XenInfo HOB is available
> - //
> - GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
> - if (GuidHob == NULL) {
> - return FALSE;
> - }
> -
> - return TRUE;
> -}
> -
> /**
> Get the address of Xen ACPI Root System Description Pointer (RSDP)
> structure.
> @@ -66,10 +42,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, "AcpiPlatformDxe: Use ACPI RSDP table at 0x%08x\n",
> + 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) {
>
Can you please split this patch in two:
(1) the first patch should only rebase AcpiPlatformDxe to the new
library, without functional changes.
(2) the second patch should add the new feature, of looking for the PVH
RSDP.
(3) In the 2nd patch, pls mention Xen in the subject line, such as:
OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist
Thanks!
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist
@ 2019-04-11 12:20 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 12:20 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> If the firmware have been started via the PVH entry point, a RSDP
> pointer would have been provided. Use it.
>
> Also, use XenDetect() from the new XenPlatformLib.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/OvmfPkgIa32.dsc | 1 +
> OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
> OvmfPkg/OvmfPkgX64.dsc | 1 +
> OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 +-
> OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h | 6 +--
> OvmfPkg/AcpiPlatformDxe/Xen.c | 41 ++++++++------------
> 6 files changed, 22 insertions(+), 30 deletions(-)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index f55ab5a3d2..cab9764cab 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -205,6 +205,7 @@ [LibraryClasses]
> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>
> !if $(TPM2_ENABLE) == TRUE
> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 5c9bdf034e..a156358690 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -210,6 +210,7 @@ [LibraryClasses]
> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>
> !if $(TPM2_ENABLE) == TRUE
> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 2943e9e8af..9d8dc442b4 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -210,6 +210,7 @@ [LibraryClasses]
> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>
> !if $(TPM2_ENABLE) == TRUE
> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> index 8440e7b343..ca54a3bd9e 100644
> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> @@ -51,13 +51,13 @@ [LibraryClasses]
> DebugLib
> UefiBootServicesTableLib
> UefiDriverEntryPoint
> - HobLib
> QemuFwCfgLib
> QemuFwCfgS3Lib
> MemoryAllocationLib
> BaseLib
> DxeServicesTableLib
> OrderedCollectionLib
> + XenPlatformLib
>
> [Protocols]
> gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> index 83b981ee00..85f37128dd 100644
> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> @@ -25,6 +25,7 @@
> #include <Library/UefiBootServicesTableLib.h>
> #include <Library/DebugLib.h>
> #include <Library/PcdLib.h>
> +#include <Library/XenPlatformLib.h>
>
> #include <IndustryStandard/Acpi.h>
>
> @@ -58,11 +59,6 @@ QemuInstallAcpiTable (
> OUT UINTN *TableKey
> );
>
> -BOOLEAN
> -XenDetected (
> - VOID
> - );
> -
> EFI_STATUS
> EFIAPI
> InstallXenTables (
> diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
> index 618ac58b42..7e9a7797d7 100644
> --- a/OvmfPkg/AcpiPlatformDxe/Xen.c
> +++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
> @@ -15,8 +15,6 @@
> **/
>
> #include "AcpiPlatform.h"
> -#include <Library/HobLib.h>
> -#include <Guid/XenInfo.h>
> #include <Library/BaseLib.h>
>
> #define XEN_ACPI_PHYSICAL_ADDRESS 0x000EA020
> @@ -24,28 +22,6 @@
>
> EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr = NULL;
>
> -/**
> - This function detects if OVMF is running on Xen.
> -
> -**/
> -BOOLEAN
> -XenDetected (
> - VOID
> - )
> -{
> - EFI_HOB_GUID_TYPE *GuidHob;
> -
> - //
> - // See if a XenInfo HOB is available
> - //
> - GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
> - if (GuidHob == NULL) {
> - return FALSE;
> - }
> -
> - return TRUE;
> -}
> -
> /**
> Get the address of Xen ACPI Root System Description Pointer (RSDP)
> structure.
> @@ -66,10 +42,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, "AcpiPlatformDxe: Use ACPI RSDP table at 0x%08x\n",
> + 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) {
>
Can you please split this patch in two:
(1) the first patch should only rebase AcpiPlatformDxe to the new
library, without functional changes.
(2) the second patch should add the new feature, of looking for the PVH
RSDP.
(3) In the 2nd patch, pls mention Xen in the subject line, such as:
OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist
Thanks!
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist
@ 2019-04-11 12:23 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 12:23 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/11/19 14:20, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> If the firmware have been started via the PVH entry point, a RSDP
>> pointer would have been provided. Use it.
>>
>> Also, use XenDetect() from the new XenPlatformLib.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/OvmfPkgIa32.dsc | 1 +
>> OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>> OvmfPkg/OvmfPkgX64.dsc | 1 +
>> OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 +-
>> OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h | 6 +--
>> OvmfPkg/AcpiPlatformDxe/Xen.c | 41 ++++++++------------
>> 6 files changed, 22 insertions(+), 30 deletions(-)
>>
>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>> index f55ab5a3d2..cab9764cab 100644
>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
>> @@ -205,6 +205,7 @@ [LibraryClasses]
>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>
>> !if $(TPM2_ENABLE) == TRUE
>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>> index 5c9bdf034e..a156358690 100644
>> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>> @@ -210,6 +210,7 @@ [LibraryClasses]
>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>
>> !if $(TPM2_ENABLE) == TRUE
>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>> index 2943e9e8af..9d8dc442b4 100644
>> --- a/OvmfPkg/OvmfPkgX64.dsc
>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>> @@ -210,6 +210,7 @@ [LibraryClasses]
>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>
>> !if $(TPM2_ENABLE) == TRUE
>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>> index 8440e7b343..ca54a3bd9e 100644
>> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>> @@ -51,13 +51,13 @@ [LibraryClasses]
>> DebugLib
>> UefiBootServicesTableLib
>> UefiDriverEntryPoint
>> - HobLib
>> QemuFwCfgLib
>> QemuFwCfgS3Lib
>> MemoryAllocationLib
>> BaseLib
>> DxeServicesTableLib
>> OrderedCollectionLib
>> + XenPlatformLib
>>
>> [Protocols]
>> gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
>> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>> index 83b981ee00..85f37128dd 100644
>> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>> @@ -25,6 +25,7 @@
>> #include <Library/UefiBootServicesTableLib.h>
>> #include <Library/DebugLib.h>
>> #include <Library/PcdLib.h>
>> +#include <Library/XenPlatformLib.h>
>>
>> #include <IndustryStandard/Acpi.h>
>>
>> @@ -58,11 +59,6 @@ QemuInstallAcpiTable (
>> OUT UINTN *TableKey
>> );
>>
>> -BOOLEAN
>> -XenDetected (
>> - VOID
>> - );
>> -
>> EFI_STATUS
>> EFIAPI
>> InstallXenTables (
>> diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
>> index 618ac58b42..7e9a7797d7 100644
>> --- a/OvmfPkg/AcpiPlatformDxe/Xen.c
>> +++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
>> @@ -15,8 +15,6 @@
>> **/
>>
>> #include "AcpiPlatform.h"
>> -#include <Library/HobLib.h>
>> -#include <Guid/XenInfo.h>
>> #include <Library/BaseLib.h>
>>
>> #define XEN_ACPI_PHYSICAL_ADDRESS 0x000EA020
>> @@ -24,28 +22,6 @@
>>
>> EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr = NULL;
>>
>> -/**
>> - This function detects if OVMF is running on Xen.
>> -
>> -**/
>> -BOOLEAN
>> -XenDetected (
>> - VOID
>> - )
>> -{
>> - EFI_HOB_GUID_TYPE *GuidHob;
>> -
>> - //
>> - // See if a XenInfo HOB is available
>> - //
>> - GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
>> - if (GuidHob == NULL) {
>> - return FALSE;
>> - }
>> -
>> - return TRUE;
>> -}
>> -
>> /**
>> Get the address of Xen ACPI Root System Description Pointer (RSDP)
>> structure.
>> @@ -66,10 +42,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, "AcpiPlatformDxe: Use ACPI RSDP table at 0x%08x\n",
>> + XenInfo->RsdpPvh));
(4) sorry, missed this one: please
- either print pointers with %p,
- or convert them with
(UINT64)(UINTN)XenInfo->RsdpPvh
and log them with "0x%016Lx".
Thanks,
Laszlo
>> + *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) {
>>
>
> Can you please split this patch in two:
>
> (1) the first patch should only rebase AcpiPlatformDxe to the new
> library, without functional changes.
>
> (2) the second patch should add the new feature, of looking for the PVH
> RSDP.
>
> (3) In the 2nd patch, pls mention Xen in the subject line, such as:
>
> OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist
>
> Thanks!
> Laszlo
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist
@ 2019-04-11 12:23 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 12:23 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/11/19 14:20, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> If the firmware have been started via the PVH entry point, a RSDP
>> pointer would have been provided. Use it.
>>
>> Also, use XenDetect() from the new XenPlatformLib.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/OvmfPkgIa32.dsc | 1 +
>> OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>> OvmfPkg/OvmfPkgX64.dsc | 1 +
>> OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 +-
>> OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h | 6 +--
>> OvmfPkg/AcpiPlatformDxe/Xen.c | 41 ++++++++------------
>> 6 files changed, 22 insertions(+), 30 deletions(-)
>>
>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>> index f55ab5a3d2..cab9764cab 100644
>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
>> @@ -205,6 +205,7 @@ [LibraryClasses]
>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>
>> !if $(TPM2_ENABLE) == TRUE
>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>> index 5c9bdf034e..a156358690 100644
>> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>> @@ -210,6 +210,7 @@ [LibraryClasses]
>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>
>> !if $(TPM2_ENABLE) == TRUE
>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>> index 2943e9e8af..9d8dc442b4 100644
>> --- a/OvmfPkg/OvmfPkgX64.dsc
>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>> @@ -210,6 +210,7 @@ [LibraryClasses]
>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>
>> !if $(TPM2_ENABLE) == TRUE
>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>> index 8440e7b343..ca54a3bd9e 100644
>> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>> @@ -51,13 +51,13 @@ [LibraryClasses]
>> DebugLib
>> UefiBootServicesTableLib
>> UefiDriverEntryPoint
>> - HobLib
>> QemuFwCfgLib
>> QemuFwCfgS3Lib
>> MemoryAllocationLib
>> BaseLib
>> DxeServicesTableLib
>> OrderedCollectionLib
>> + XenPlatformLib
>>
>> [Protocols]
>> gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
>> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>> index 83b981ee00..85f37128dd 100644
>> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>> @@ -25,6 +25,7 @@
>> #include <Library/UefiBootServicesTableLib.h>
>> #include <Library/DebugLib.h>
>> #include <Library/PcdLib.h>
>> +#include <Library/XenPlatformLib.h>
>>
>> #include <IndustryStandard/Acpi.h>
>>
>> @@ -58,11 +59,6 @@ QemuInstallAcpiTable (
>> OUT UINTN *TableKey
>> );
>>
>> -BOOLEAN
>> -XenDetected (
>> - VOID
>> - );
>> -
>> EFI_STATUS
>> EFIAPI
>> InstallXenTables (
>> diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
>> index 618ac58b42..7e9a7797d7 100644
>> --- a/OvmfPkg/AcpiPlatformDxe/Xen.c
>> +++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
>> @@ -15,8 +15,6 @@
>> **/
>>
>> #include "AcpiPlatform.h"
>> -#include <Library/HobLib.h>
>> -#include <Guid/XenInfo.h>
>> #include <Library/BaseLib.h>
>>
>> #define XEN_ACPI_PHYSICAL_ADDRESS 0x000EA020
>> @@ -24,28 +22,6 @@
>>
>> EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr = NULL;
>>
>> -/**
>> - This function detects if OVMF is running on Xen.
>> -
>> -**/
>> -BOOLEAN
>> -XenDetected (
>> - VOID
>> - )
>> -{
>> - EFI_HOB_GUID_TYPE *GuidHob;
>> -
>> - //
>> - // See if a XenInfo HOB is available
>> - //
>> - GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
>> - if (GuidHob == NULL) {
>> - return FALSE;
>> - }
>> -
>> - return TRUE;
>> -}
>> -
>> /**
>> Get the address of Xen ACPI Root System Description Pointer (RSDP)
>> structure.
>> @@ -66,10 +42,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, "AcpiPlatformDxe: Use ACPI RSDP table at 0x%08x\n",
>> + XenInfo->RsdpPvh));
(4) sorry, missed this one: please
- either print pointers with %p,
- or convert them with
(UINT64)(UINTN)XenInfo->RsdpPvh
and log them with "0x%016Lx".
Thanks,
Laszlo
>> + *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) {
>>
>
> Can you please split this patch in two:
>
> (1) the first patch should only rebase AcpiPlatformDxe to the new
> library, without functional changes.
>
> (2) the second patch should add the new feature, of looking for the PVH
> RSDP.
>
> (3) In the 2nd patch, pls mention Xen in the subject line, such as:
>
> OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist
>
> Thanks!
> Laszlo
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist
@ 2019-04-11 12:31 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 12:31 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/11/19 14:23, Laszlo Ersek wrote:
> On 04/11/19 14:20, Laszlo Ersek wrote:
>> On 04/09/19 13:08, Anthony PERARD wrote:
>>> If the firmware have been started via the PVH entry point, a RSDP
>>> pointer would have been provided. Use it.
>>>
>>> Also, use XenDetect() from the new XenPlatformLib.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>> ---
>>> OvmfPkg/OvmfPkgIa32.dsc | 1 +
>>> OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>>> OvmfPkg/OvmfPkgX64.dsc | 1 +
>>> OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 +-
>>> OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h | 6 +--
>>> OvmfPkg/AcpiPlatformDxe/Xen.c | 41 ++++++++------------
>>> 6 files changed, 22 insertions(+), 30 deletions(-)
>>>
>>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>>> index f55ab5a3d2..cab9764cab 100644
>>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
>>> @@ -205,6 +205,7 @@ [LibraryClasses]
>>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>>
>>> !if $(TPM2_ENABLE) == TRUE
>>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>>> index 5c9bdf034e..a156358690 100644
>>> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
>>> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>>> @@ -210,6 +210,7 @@ [LibraryClasses]
>>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>>
>>> !if $(TPM2_ENABLE) == TRUE
>>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>>> index 2943e9e8af..9d8dc442b4 100644
>>> --- a/OvmfPkg/OvmfPkgX64.dsc
>>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>>> @@ -210,6 +210,7 @@ [LibraryClasses]
>>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>>
>>> !if $(TPM2_ENABLE) == TRUE
>>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>>> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>>> index 8440e7b343..ca54a3bd9e 100644
>>> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>>> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>>> @@ -51,13 +51,13 @@ [LibraryClasses]
>>> DebugLib
>>> UefiBootServicesTableLib
>>> UefiDriverEntryPoint
>>> - HobLib
>>> QemuFwCfgLib
>>> QemuFwCfgS3Lib
>>> MemoryAllocationLib
>>> BaseLib
>>> DxeServicesTableLib
>>> OrderedCollectionLib
>>> + XenPlatformLib
>>>
>>> [Protocols]
>>> gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
>>> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>>> index 83b981ee00..85f37128dd 100644
>>> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>>> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>>> @@ -25,6 +25,7 @@
>>> #include <Library/UefiBootServicesTableLib.h>
>>> #include <Library/DebugLib.h>
>>> #include <Library/PcdLib.h>
>>> +#include <Library/XenPlatformLib.h>
>>>
>>> #include <IndustryStandard/Acpi.h>
>>>
>>> @@ -58,11 +59,6 @@ QemuInstallAcpiTable (
>>> OUT UINTN *TableKey
>>> );
>>>
>>> -BOOLEAN
>>> -XenDetected (
>>> - VOID
>>> - );
>>> -
>>> EFI_STATUS
>>> EFIAPI
>>> InstallXenTables (
>>> diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
>>> index 618ac58b42..7e9a7797d7 100644
>>> --- a/OvmfPkg/AcpiPlatformDxe/Xen.c
>>> +++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
>>> @@ -15,8 +15,6 @@
>>> **/
>>>
>>> #include "AcpiPlatform.h"
>>> -#include <Library/HobLib.h>
>>> -#include <Guid/XenInfo.h>
>>> #include <Library/BaseLib.h>
>>>
>>> #define XEN_ACPI_PHYSICAL_ADDRESS 0x000EA020
>>> @@ -24,28 +22,6 @@
>>>
>>> EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr = NULL;
>>>
>>> -/**
>>> - This function detects if OVMF is running on Xen.
>>> -
>>> -**/
>>> -BOOLEAN
>>> -XenDetected (
>>> - VOID
>>> - )
>>> -{
>>> - EFI_HOB_GUID_TYPE *GuidHob;
>>> -
>>> - //
>>> - // See if a XenInfo HOB is available
>>> - //
>>> - GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
>>> - if (GuidHob == NULL) {
>>> - return FALSE;
>>> - }
>>> -
>>> - return TRUE;
>>> -}
>>> -
>>> /**
>>> Get the address of Xen ACPI Root System Description Pointer (RSDP)
>>> structure.
>>> @@ -66,10 +42,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, "AcpiPlatformDxe: Use ACPI RSDP table at 0x%08x\n",
>>> + XenInfo->RsdpPvh));
>
> (4) sorry, missed this one: please
>
> - either print pointers with %p,
>
> - or convert them with
>
> (UINT64)(UINTN)XenInfo->RsdpPvh
>
> and log them with "0x%016Lx".
Sigh, I clearly need to cease reviewing this series for today. Here's
another remark:
(5) if you want to print the name of the module (such as
"AcpiPlatformDxe") in a log message, please use the "%a" format
specifier (for "ASCII string"), and use the following auto-generated
variable:
gEfiCallerBaseName
It will contain the BASE_NAME string from the module INF file.
This variable is particularly useful in files that are built into
multiple modules:
- for example, a module directory may contain two INF files, with
different BASE_NAMEs, and include a common .c file. If that .c file
produces log messages, gEfiCallerBaseName is helpful.
- the same applies even more to log messages generated from libraries --
you'll want to see the name of the driver or application that the
library is linked into. In that case, gEfiCallerBaseName refers to the
BASE_NAME of the driver/app INF file, and not the lib instance INF
file.
Thanks
Laszlo
>>> + *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) {
>>>
>>
>> Can you please split this patch in two:
>>
>> (1) the first patch should only rebase AcpiPlatformDxe to the new
>> library, without functional changes.
>>
>> (2) the second patch should add the new feature, of looking for the PVH
>> RSDP.
>>
>> (3) In the 2nd patch, pls mention Xen in the subject line, such as:
>>
>> OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist
>>
>> Thanks!
>> Laszlo
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist
@ 2019-04-11 12:31 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-11 12:31 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/11/19 14:23, Laszlo Ersek wrote:
> On 04/11/19 14:20, Laszlo Ersek wrote:
>> On 04/09/19 13:08, Anthony PERARD wrote:
>>> If the firmware have been started via the PVH entry point, a RSDP
>>> pointer would have been provided. Use it.
>>>
>>> Also, use XenDetect() from the new XenPlatformLib.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>> ---
>>> OvmfPkg/OvmfPkgIa32.dsc | 1 +
>>> OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>>> OvmfPkg/OvmfPkgX64.dsc | 1 +
>>> OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 +-
>>> OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h | 6 +--
>>> OvmfPkg/AcpiPlatformDxe/Xen.c | 41 ++++++++------------
>>> 6 files changed, 22 insertions(+), 30 deletions(-)
>>>
>>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>>> index f55ab5a3d2..cab9764cab 100644
>>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
>>> @@ -205,6 +205,7 @@ [LibraryClasses]
>>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>>
>>> !if $(TPM2_ENABLE) == TRUE
>>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>>> index 5c9bdf034e..a156358690 100644
>>> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
>>> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>>> @@ -210,6 +210,7 @@ [LibraryClasses]
>>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>>
>>> !if $(TPM2_ENABLE) == TRUE
>>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>>> index 2943e9e8af..9d8dc442b4 100644
>>> --- a/OvmfPkg/OvmfPkgX64.dsc
>>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>>> @@ -210,6 +210,7 @@ [LibraryClasses]
>>> SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
>>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>>> + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
>>>
>>> !if $(TPM2_ENABLE) == TRUE
>>> Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>>> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>>> index 8440e7b343..ca54a3bd9e 100644
>>> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>>> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>>> @@ -51,13 +51,13 @@ [LibraryClasses]
>>> DebugLib
>>> UefiBootServicesTableLib
>>> UefiDriverEntryPoint
>>> - HobLib
>>> QemuFwCfgLib
>>> QemuFwCfgS3Lib
>>> MemoryAllocationLib
>>> BaseLib
>>> DxeServicesTableLib
>>> OrderedCollectionLib
>>> + XenPlatformLib
>>>
>>> [Protocols]
>>> gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
>>> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>>> index 83b981ee00..85f37128dd 100644
>>> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>>> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
>>> @@ -25,6 +25,7 @@
>>> #include <Library/UefiBootServicesTableLib.h>
>>> #include <Library/DebugLib.h>
>>> #include <Library/PcdLib.h>
>>> +#include <Library/XenPlatformLib.h>
>>>
>>> #include <IndustryStandard/Acpi.h>
>>>
>>> @@ -58,11 +59,6 @@ QemuInstallAcpiTable (
>>> OUT UINTN *TableKey
>>> );
>>>
>>> -BOOLEAN
>>> -XenDetected (
>>> - VOID
>>> - );
>>> -
>>> EFI_STATUS
>>> EFIAPI
>>> InstallXenTables (
>>> diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
>>> index 618ac58b42..7e9a7797d7 100644
>>> --- a/OvmfPkg/AcpiPlatformDxe/Xen.c
>>> +++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
>>> @@ -15,8 +15,6 @@
>>> **/
>>>
>>> #include "AcpiPlatform.h"
>>> -#include <Library/HobLib.h>
>>> -#include <Guid/XenInfo.h>
>>> #include <Library/BaseLib.h>
>>>
>>> #define XEN_ACPI_PHYSICAL_ADDRESS 0x000EA020
>>> @@ -24,28 +22,6 @@
>>>
>>> EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr = NULL;
>>>
>>> -/**
>>> - This function detects if OVMF is running on Xen.
>>> -
>>> -**/
>>> -BOOLEAN
>>> -XenDetected (
>>> - VOID
>>> - )
>>> -{
>>> - EFI_HOB_GUID_TYPE *GuidHob;
>>> -
>>> - //
>>> - // See if a XenInfo HOB is available
>>> - //
>>> - GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
>>> - if (GuidHob == NULL) {
>>> - return FALSE;
>>> - }
>>> -
>>> - return TRUE;
>>> -}
>>> -
>>> /**
>>> Get the address of Xen ACPI Root System Description Pointer (RSDP)
>>> structure.
>>> @@ -66,10 +42,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, "AcpiPlatformDxe: Use ACPI RSDP table at 0x%08x\n",
>>> + XenInfo->RsdpPvh));
>
> (4) sorry, missed this one: please
>
> - either print pointers with %p,
>
> - or convert them with
>
> (UINT64)(UINTN)XenInfo->RsdpPvh
>
> and log them with "0x%016Lx".
Sigh, I clearly need to cease reviewing this series for today. Here's
another remark:
(5) if you want to print the name of the module (such as
"AcpiPlatformDxe") in a log message, please use the "%a" format
specifier (for "ASCII string"), and use the following auto-generated
variable:
gEfiCallerBaseName
It will contain the BASE_NAME string from the module INF file.
This variable is particularly useful in files that are built into
multiple modules:
- for example, a module directory may contain two INF files, with
different BASE_NAMEs, and include a common .c file. If that .c file
produces log messages, gEfiCallerBaseName is helpful.
- the same applies even more to log messages generated from libraries --
you'll want to see the name of the driver or application that the
library is linked into. In that case, gEfiCallerBaseName refers to the
BASE_NAME of the driver/app INF file, and not the lib instance INF
file.
Thanks
Laszlo
>>> + *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) {
>>>
>>
>> Can you please split this patch in two:
>>
>> (1) the first patch should only rebase AcpiPlatformDxe to the new
>> library, without functional changes.
>>
>> (2) the second patch should add the new feature, of looking for the PVH
>> RSDP.
>>
>> (3) In the 2nd patch, pls mention Xen in the subject line, such as:
>>
>> OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist
>>
>> Thanks!
>> Laszlo
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 15/31] OvmfPkg/XenHypercallLib: Enable it in PEIM
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Allow to use Xen hypercalls earlier, during the PEIM stage, but
XenHypercallLibReInit() must be called once the XenInfo HOB is created
with the HyperPage setup.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf | 2 +-
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
OvmfPkg/Include/Library/XenHypercallLib.h | 12 ++++++++++++
OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c | 11 +++++++++++
OvmfPkg/XenPlatformPei/Xen.c | 7 +++++++
5 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
index d268e540fe..e0a1889171 100644
--- a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
@@ -21,7 +21,7 @@ [Defines]
CONSTRUCTOR = XenHypercallLibInit
[Defines.IA32, Defines.X64]
- LIBRARY_CLASS = XenHypercallLib|DXE_DRIVER UEFI_DRIVER
+ LIBRARY_CLASS = XenHypercallLib|PEIM DXE_DRIVER UEFI_DRIVER
[Defines.ARM, Defines.AARCH64]
LIBRARY_CLASS = XenHypercallLib
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 1870e39208..bc6065a709 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -66,6 +66,7 @@ [LibraryClasses]
MtrrLib
MemEncryptSevLib
PcdLib
+ XenHypercallLib
[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
diff --git a/OvmfPkg/Include/Library/XenHypercallLib.h b/OvmfPkg/Include/Library/XenHypercallLib.h
index 36e3344e2f..38e64ab108 100644
--- a/OvmfPkg/Include/Library/XenHypercallLib.h
+++ b/OvmfPkg/Include/Library/XenHypercallLib.h
@@ -16,6 +16,18 @@
#ifndef __XEN_HYPERCALL_LIB_H__
#define __XEN_HYPERCALL_LIB_H__
+/**
+ To call when the gEfiXenInfoGuid HOB became available after the library init
+ function has already been executed.
+
+ This allow to make hypercall in the PEIM stage.
+**/
+VOID
+EFIAPI
+XenHypercallLibReInit (
+ VOID
+ );
+
/**
Check if the Xen Hypercall library is able to make calls to the Xen
hypervisor.
diff --git a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
index 7cb7f46c9b..2ac7254759 100644
--- a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
+++ b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
@@ -78,6 +78,17 @@ XenHypercallLibInit (
return RETURN_SUCCESS;
}
+VOID
+EFIAPI
+XenHypercallLibReInit (
+ VOID
+ )
+{
+ if (HyperPage == NULL) {
+ XenHypercallLibInit();
+ }
+}
+
/**
This function will put the two arguments in the right place (registers) and
invoke the hypercall identified by HypercallID.
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index fb01094ba9..9d9e9f8020 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -32,6 +32,7 @@
#include <Library/ResourcePublicationLib.h>
#include <Library/MtrrLib.h>
#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
+#include <Library/XenHypercallLib.h>
#include "Platform.h"
#include "Xen.h"
@@ -157,6 +158,12 @@ XenConnect (
sizeof(mXenInfo)
);
+ //
+ // Initialize the XenHypercall library, now that the XenInfo HOB is
+ // available
+ //
+ XenHypercallLibReInit ();
+
return EFI_SUCCESS;
}
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 15/31] OvmfPkg/XenHypercallLib: Enable it in PEIM
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Allow to use Xen hypercalls earlier, during the PEIM stage, but
XenHypercallLibReInit() must be called once the XenInfo HOB is created
with the HyperPage setup.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf | 2 +-
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
OvmfPkg/Include/Library/XenHypercallLib.h | 12 ++++++++++++
OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c | 11 +++++++++++
OvmfPkg/XenPlatformPei/Xen.c | 7 +++++++
5 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
index d268e540fe..e0a1889171 100644
--- a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
@@ -21,7 +21,7 @@ [Defines]
CONSTRUCTOR = XenHypercallLibInit
[Defines.IA32, Defines.X64]
- LIBRARY_CLASS = XenHypercallLib|DXE_DRIVER UEFI_DRIVER
+ LIBRARY_CLASS = XenHypercallLib|PEIM DXE_DRIVER UEFI_DRIVER
[Defines.ARM, Defines.AARCH64]
LIBRARY_CLASS = XenHypercallLib
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 1870e39208..bc6065a709 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -66,6 +66,7 @@ [LibraryClasses]
MtrrLib
MemEncryptSevLib
PcdLib
+ XenHypercallLib
[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
diff --git a/OvmfPkg/Include/Library/XenHypercallLib.h b/OvmfPkg/Include/Library/XenHypercallLib.h
index 36e3344e2f..38e64ab108 100644
--- a/OvmfPkg/Include/Library/XenHypercallLib.h
+++ b/OvmfPkg/Include/Library/XenHypercallLib.h
@@ -16,6 +16,18 @@
#ifndef __XEN_HYPERCALL_LIB_H__
#define __XEN_HYPERCALL_LIB_H__
+/**
+ To call when the gEfiXenInfoGuid HOB became available after the library init
+ function has already been executed.
+
+ This allow to make hypercall in the PEIM stage.
+**/
+VOID
+EFIAPI
+XenHypercallLibReInit (
+ VOID
+ );
+
/**
Check if the Xen Hypercall library is able to make calls to the Xen
hypervisor.
diff --git a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
index 7cb7f46c9b..2ac7254759 100644
--- a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
+++ b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
@@ -78,6 +78,17 @@ XenHypercallLibInit (
return RETURN_SUCCESS;
}
+VOID
+EFIAPI
+XenHypercallLibReInit (
+ VOID
+ )
+{
+ if (HyperPage == NULL) {
+ XenHypercallLibInit();
+ }
+}
+
/**
This function will put the two arguments in the right place (registers) and
invoke the hypercall identified by HypercallID.
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index fb01094ba9..9d9e9f8020 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -32,6 +32,7 @@
#include <Library/ResourcePublicationLib.h>
#include <Library/MtrrLib.h>
#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
+#include <Library/XenHypercallLib.h>
#include "Platform.h"
#include "Xen.h"
@@ -157,6 +158,12 @@ XenConnect (
sizeof(mXenInfo)
);
+ //
+ // Initialize the XenHypercall library, now that the XenInfo HOB is
+ // available
+ //
+ XenHypercallLibReInit ();
+
return EFI_SUCCESS;
}
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 15/31] OvmfPkg/XenHypercallLib: Enable it in PEIM
@ 2019-04-12 9:07 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:07 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Allow to use Xen hypercalls earlier, during the PEIM stage, but
> XenHypercallLibReInit() must be called once the XenInfo HOB is created
> with the HyperPage setup.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf | 2 +-
> OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
> OvmfPkg/Include/Library/XenHypercallLib.h | 12 ++++++++++++
> OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c | 11 +++++++++++
> OvmfPkg/XenPlatformPei/Xen.c | 7 +++++++
> 5 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> index d268e540fe..e0a1889171 100644
> --- a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> +++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> @@ -21,7 +21,7 @@ [Defines]
> CONSTRUCTOR = XenHypercallLibInit
>
> [Defines.IA32, Defines.X64]
> - LIBRARY_CLASS = XenHypercallLib|DXE_DRIVER UEFI_DRIVER
> + LIBRARY_CLASS = XenHypercallLib|PEIM DXE_DRIVER UEFI_DRIVER
>
> [Defines.ARM, Defines.AARCH64]
> LIBRARY_CLASS = XenHypercallLib
> diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> index 1870e39208..bc6065a709 100644
> --- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> +++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> @@ -66,6 +66,7 @@ [LibraryClasses]
> MtrrLib
> MemEncryptSevLib
> PcdLib
> + XenHypercallLib
>
> [Pcd]
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
> diff --git a/OvmfPkg/Include/Library/XenHypercallLib.h b/OvmfPkg/Include/Library/XenHypercallLib.h
> index 36e3344e2f..38e64ab108 100644
> --- a/OvmfPkg/Include/Library/XenHypercallLib.h
> +++ b/OvmfPkg/Include/Library/XenHypercallLib.h
> @@ -16,6 +16,18 @@
> #ifndef __XEN_HYPERCALL_LIB_H__
> #define __XEN_HYPERCALL_LIB_H__
>
> +/**
> + To call when the gEfiXenInfoGuid HOB became available after the library init
> + function has already been executed.
> +
> + This allow to make hypercall in the PEIM stage.
> +**/
> +VOID
> +EFIAPI
> +XenHypercallLibReInit (
> + VOID
> + );
> +
> /**
> Check if the Xen Hypercall library is able to make calls to the Xen
> hypervisor.
> diff --git a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
> index 7cb7f46c9b..2ac7254759 100644
> --- a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
> +++ b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
> @@ -78,6 +78,17 @@ XenHypercallLibInit (
> return RETURN_SUCCESS;
> }
>
> +VOID
> +EFIAPI
> +XenHypercallLibReInit (
> + VOID
> + )
> +{
> + if (HyperPage == NULL) {
> + XenHypercallLibInit();
> + }
> +}
> +
> /**
> This function will put the two arguments in the right place (registers) and
> invoke the hypercall identified by HypercallID.
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index fb01094ba9..9d9e9f8020 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -32,6 +32,7 @@
> #include <Library/ResourcePublicationLib.h>
> #include <Library/MtrrLib.h>
> #include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
> +#include <Library/XenHypercallLib.h>
>
> #include "Platform.h"
> #include "Xen.h"
> @@ -157,6 +158,12 @@ XenConnect (
> sizeof(mXenInfo)
> );
>
> + //
> + // Initialize the XenHypercall library, now that the XenInfo HOB is
> + // available
> + //
> + XenHypercallLibReInit ();
> +
> return EFI_SUCCESS;
> }
>
>
Please rework this patch as follows. We're going to need two patches.
First patch:
(1) In "X86XenHypercall.c", change XenHypercallLibInit() to return
RETURN_NOT_FOUND, when it doesn't find the HOB. Remove the comment about
constructors.
(2) Add the prototype of the existing XenHypercallLibInit() function to
"XenHypercallLib.h".
(3) In "XenHypercall.c", introduce a new function called
XenHypercallLibConstruct(). This function should have identical return
type, calling convention, and parameter list, to XenHypercallLibInit().
The new function should call XenHypercallLibInit(), ignore its return
value, and always return RETURN_SUCCESS. Reinstate the comment here that
you removed in (1).
(4) Update the CONSTRUCTOR define in the INF file to
XenHypercallLibConstruct.
(5) Don't touch XenPlatformPei.
Second patch:
(6) Make XenPlatformPei call XenHypercallLibInit(), and then assert success:
RETURN_STATUS XenHypercallInitStatus;
XenHypercallInitStatus = XenHypercallLibInit ();
ASSERT_RETURN_ERROR (XenHypercallInitStatus);
Thanks,
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 15/31] OvmfPkg/XenHypercallLib: Enable it in PEIM
@ 2019-04-12 9:07 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:07 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Allow to use Xen hypercalls earlier, during the PEIM stage, but
> XenHypercallLibReInit() must be called once the XenInfo HOB is created
> with the HyperPage setup.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf | 2 +-
> OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
> OvmfPkg/Include/Library/XenHypercallLib.h | 12 ++++++++++++
> OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c | 11 +++++++++++
> OvmfPkg/XenPlatformPei/Xen.c | 7 +++++++
> 5 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> index d268e540fe..e0a1889171 100644
> --- a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> +++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> @@ -21,7 +21,7 @@ [Defines]
> CONSTRUCTOR = XenHypercallLibInit
>
> [Defines.IA32, Defines.X64]
> - LIBRARY_CLASS = XenHypercallLib|DXE_DRIVER UEFI_DRIVER
> + LIBRARY_CLASS = XenHypercallLib|PEIM DXE_DRIVER UEFI_DRIVER
>
> [Defines.ARM, Defines.AARCH64]
> LIBRARY_CLASS = XenHypercallLib
> diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> index 1870e39208..bc6065a709 100644
> --- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> +++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> @@ -66,6 +66,7 @@ [LibraryClasses]
> MtrrLib
> MemEncryptSevLib
> PcdLib
> + XenHypercallLib
>
> [Pcd]
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
> diff --git a/OvmfPkg/Include/Library/XenHypercallLib.h b/OvmfPkg/Include/Library/XenHypercallLib.h
> index 36e3344e2f..38e64ab108 100644
> --- a/OvmfPkg/Include/Library/XenHypercallLib.h
> +++ b/OvmfPkg/Include/Library/XenHypercallLib.h
> @@ -16,6 +16,18 @@
> #ifndef __XEN_HYPERCALL_LIB_H__
> #define __XEN_HYPERCALL_LIB_H__
>
> +/**
> + To call when the gEfiXenInfoGuid HOB became available after the library init
> + function has already been executed.
> +
> + This allow to make hypercall in the PEIM stage.
> +**/
> +VOID
> +EFIAPI
> +XenHypercallLibReInit (
> + VOID
> + );
> +
> /**
> Check if the Xen Hypercall library is able to make calls to the Xen
> hypervisor.
> diff --git a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
> index 7cb7f46c9b..2ac7254759 100644
> --- a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
> +++ b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
> @@ -78,6 +78,17 @@ XenHypercallLibInit (
> return RETURN_SUCCESS;
> }
>
> +VOID
> +EFIAPI
> +XenHypercallLibReInit (
> + VOID
> + )
> +{
> + if (HyperPage == NULL) {
> + XenHypercallLibInit();
> + }
> +}
> +
> /**
> This function will put the two arguments in the right place (registers) and
> invoke the hypercall identified by HypercallID.
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index fb01094ba9..9d9e9f8020 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -32,6 +32,7 @@
> #include <Library/ResourcePublicationLib.h>
> #include <Library/MtrrLib.h>
> #include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
> +#include <Library/XenHypercallLib.h>
>
> #include "Platform.h"
> #include "Xen.h"
> @@ -157,6 +158,12 @@ XenConnect (
> sizeof(mXenInfo)
> );
>
> + //
> + // Initialize the XenHypercall library, now that the XenInfo HOB is
> + // available
> + //
> + XenHypercallLibReInit ();
> +
> return EFI_SUCCESS;
> }
>
>
Please rework this patch as follows. We're going to need two patches.
First patch:
(1) In "X86XenHypercall.c", change XenHypercallLibInit() to return
RETURN_NOT_FOUND, when it doesn't find the HOB. Remove the comment about
constructors.
(2) Add the prototype of the existing XenHypercallLibInit() function to
"XenHypercallLib.h".
(3) In "XenHypercall.c", introduce a new function called
XenHypercallLibConstruct(). This function should have identical return
type, calling convention, and parameter list, to XenHypercallLibInit().
The new function should call XenHypercallLibInit(), ignore its return
value, and always return RETURN_SUCCESS. Reinstate the comment here that
you removed in (1).
(4) Update the CONSTRUCTOR define in the INF file to
XenHypercallLibConstruct.
(5) Don't touch XenPlatformPei.
Second patch:
(6) Make XenPlatformPei call XenHypercallLibInit(), and then assert success:
RETURN_STATUS XenHypercallInitStatus;
XenHypercallInitStatus = XenHypercallLibInit ();
ASSERT_RETURN_ERROR (XenHypercallInitStatus);
Thanks,
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 16/31] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
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 6ccd5eb66c..5565d47e34 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -95,6 +95,11 @@ XenDetect (
VOID
);
+BOOLEAN
+XenHvmloaderDetected (
+ VOID
+ );
+
VOID
AmdSevInitialize (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 9d9e9f8020..89933ec3e9 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -202,6 +202,13 @@ XenDetect (
return FALSE;
}
+BOOLEAN
+XenHvmloaderDetected (
+ VOID
+ )
+{
+ return (mXenHvmloaderInfo != NULL);
+}
VOID
XenPublishRamRegions (
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 16/31] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
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 6ccd5eb66c..5565d47e34 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -95,6 +95,11 @@ XenDetect (
VOID
);
+BOOLEAN
+XenHvmloaderDetected (
+ VOID
+ );
+
VOID
AmdSevInitialize (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 9d9e9f8020..89933ec3e9 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -202,6 +202,13 @@ XenDetect (
return FALSE;
}
+BOOLEAN
+XenHvmloaderDetected (
+ VOID
+ )
+{
+ return (mXenHvmloaderInfo != NULL);
+}
VOID
XenPublishRamRegions (
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 16/31] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected
@ 2019-04-12 9:08 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:08 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 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 6ccd5eb66c..5565d47e34 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -95,6 +95,11 @@ XenDetect (
> VOID
> );
>
> +BOOLEAN
> +XenHvmloaderDetected (
> + VOID
> + );
> +
> VOID
> AmdSevInitialize (
> VOID
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 9d9e9f8020..89933ec3e9 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -202,6 +202,13 @@ XenDetect (
> return FALSE;
> }
>
> +BOOLEAN
> +XenHvmloaderDetected (
> + VOID
> + )
> +{
> + return (mXenHvmloaderInfo != NULL);
> +}
>
> VOID
> XenPublishRamRegions (
>
(1) Please add least one sentence to the commit message body.
With that:
Acked-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 16/31] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected
@ 2019-04-12 9:08 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:08 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 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 6ccd5eb66c..5565d47e34 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -95,6 +95,11 @@ XenDetect (
> VOID
> );
>
> +BOOLEAN
> +XenHvmloaderDetected (
> + VOID
> + );
> +
> VOID
> AmdSevInitialize (
> VOID
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 9d9e9f8020..89933ec3e9 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -202,6 +202,13 @@ XenDetect (
> return FALSE;
> }
>
> +BOOLEAN
> +XenHvmloaderDetected (
> + VOID
> + )
> +{
> + return (mXenHvmloaderInfo != NULL);
> +}
>
> VOID
> XenPublishRamRegions (
>
(1) Please add least one sentence to the commit message body.
With that:
Acked-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 17/31] OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it as runned
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenPlatformPei/Xen.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 89933ec3e9..22c7a22c88 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -275,7 +275,9 @@ InitializeXen (
// Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
// This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
//
- AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
+ if (XenHvmloaderDetected ()) {
+ AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
+ }
PcdStatus = PcdSetBoolS (PcdPciDisableBusEnumeration, TRUE);
ASSERT_RETURN_ERROR (PcdStatus);
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 17/31] OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it as runned
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenPlatformPei/Xen.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 89933ec3e9..22c7a22c88 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -275,7 +275,9 @@ InitializeXen (
// Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
// This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
//
- AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
+ if (XenHvmloaderDetected ()) {
+ AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
+ }
PcdStatus = PcdSetBoolS (PcdPciDisableBusEnumeration, TRUE);
ASSERT_RETURN_ERROR (PcdStatus);
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 17/31] OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it as runned
@ 2019-04-12 9:09 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:09 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenPlatformPei/Xen.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 89933ec3e9..22c7a22c88 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -275,7 +275,9 @@ InitializeXen (
> // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
> // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
> //
> - AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
> + if (XenHvmloaderDetected ()) {
> + AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
> + }
>
> PcdStatus = PcdSetBoolS (PcdPciDisableBusEnumeration, TRUE);
> ASSERT_RETURN_ERROR (PcdStatus);
>
(1) please fix the subject: s/as runned/has run/
(2) please write a nonempty commit message body.
With that:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 17/31] OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it as runned
@ 2019-04-12 9:09 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:09 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenPlatformPei/Xen.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 89933ec3e9..22c7a22c88 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -275,7 +275,9 @@ InitializeXen (
> // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
> // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
> //
> - AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
> + if (XenHvmloaderDetected ()) {
> + AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
> + }
>
> PcdStatus = PcdSetBoolS (PcdPciDisableBusEnumeration, TRUE);
> ASSERT_RETURN_ERROR (PcdStatus);
>
(1) please fix the subject: s/as runned/has run/
(2) please write a nonempty commit message body.
With that:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 18/31] OvmfPkg/XenPlatformPei: Setup HyperPages earlier
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
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().
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
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 5565d47e34..a524c23a43 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -85,6 +85,11 @@ InstallClearCacheCallback (
VOID
);
+EFI_STATUS
+XenConnect (
+ VOID
+ );
+
EFI_STATUS
InitializeXen (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
index 2d567a4760..5e6d553ad5 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -421,6 +421,8 @@ InitializeXenPlatform (
CpuDeadLoop ();
}
+ XenConnect ();
+
BootModeInitialization ();
AddressWidthInitialization ();
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 22c7a22c88..b36eff524d 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -78,14 +78,11 @@ XenGetE820Map (
/**
Connects to the Hypervisor.
- @param XenLeaf CPUID index used to connect.
-
@return EFI_STATUS
**/
EFI_STATUS
XenConnect (
- UINT32 XenLeaf
)
{
UINT32 Index;
@@ -96,7 +93,13 @@ XenConnect (
CHAR8 Sig[sizeof (Info->Signature) + 1];
UINT32 *PVHResetVectorData;
- AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
+ ASSERT (mXenLeaf != 0);
+
+ //
+ // Prepare HyperPages to be able to make hypercalls
+ //
+
+ AsmCpuid (mXenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
if (!mXenInfo.HyperPages) {
return EFI_OUT_OF_RESOURCES;
@@ -108,7 +111,11 @@ XenConnect (
(Index << EFI_PAGE_SHIFT) + Index);
}
- AsmCpuid (XenLeaf + 1, &XenVersion, NULL, NULL, NULL);
+ //
+ // Find out the Xen version
+ //
+
+ AsmCpuid (mXenLeaf + 1, &XenVersion, NULL, NULL, NULL);
DEBUG ((EFI_D_ERROR, "Detected Xen version %d.%d\n",
XenVersion >> 16, XenVersion & 0xFFFF));
mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
@@ -265,12 +272,6 @@ InitializeXen (
{
RETURN_STATUS PcdStatus;
- if (mXenLeaf == 0) {
- return EFI_NOT_FOUND;
- }
-
- XenConnect (mXenLeaf);
-
//
// Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
// This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 18/31] OvmfPkg/XenPlatformPei: Setup HyperPages earlier
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
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().
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
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 5565d47e34..a524c23a43 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -85,6 +85,11 @@ InstallClearCacheCallback (
VOID
);
+EFI_STATUS
+XenConnect (
+ VOID
+ );
+
EFI_STATUS
InitializeXen (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
index 2d567a4760..5e6d553ad5 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -421,6 +421,8 @@ InitializeXenPlatform (
CpuDeadLoop ();
}
+ XenConnect ();
+
BootModeInitialization ();
AddressWidthInitialization ();
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 22c7a22c88..b36eff524d 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -78,14 +78,11 @@ XenGetE820Map (
/**
Connects to the Hypervisor.
- @param XenLeaf CPUID index used to connect.
-
@return EFI_STATUS
**/
EFI_STATUS
XenConnect (
- UINT32 XenLeaf
)
{
UINT32 Index;
@@ -96,7 +93,13 @@ XenConnect (
CHAR8 Sig[sizeof (Info->Signature) + 1];
UINT32 *PVHResetVectorData;
- AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
+ ASSERT (mXenLeaf != 0);
+
+ //
+ // Prepare HyperPages to be able to make hypercalls
+ //
+
+ AsmCpuid (mXenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
if (!mXenInfo.HyperPages) {
return EFI_OUT_OF_RESOURCES;
@@ -108,7 +111,11 @@ XenConnect (
(Index << EFI_PAGE_SHIFT) + Index);
}
- AsmCpuid (XenLeaf + 1, &XenVersion, NULL, NULL, NULL);
+ //
+ // Find out the Xen version
+ //
+
+ AsmCpuid (mXenLeaf + 1, &XenVersion, NULL, NULL, NULL);
DEBUG ((EFI_D_ERROR, "Detected Xen version %d.%d\n",
XenVersion >> 16, XenVersion & 0xFFFF));
mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
@@ -265,12 +272,6 @@ InitializeXen (
{
RETURN_STATUS PcdStatus;
- if (mXenLeaf == 0) {
- return EFI_NOT_FOUND;
- }
-
- XenConnect (mXenLeaf);
-
//
// Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
// This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 18/31] OvmfPkg/XenPlatformPei: Setup HyperPages earlier
@ 2019-04-12 9:17 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:17 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> 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().
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 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 5565d47e34..a524c23a43 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -85,6 +85,11 @@ InstallClearCacheCallback (
> VOID
> );
>
> +EFI_STATUS
> +XenConnect (
> + VOID
> + );
> +
> EFI_STATUS
> InitializeXen (
> VOID
> diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
> index 2d567a4760..5e6d553ad5 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -421,6 +421,8 @@ InitializeXenPlatform (
> CpuDeadLoop ();
> }
>
> + XenConnect ();
> +
> BootModeInitialization ();
> AddressWidthInitialization ();
>
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 22c7a22c88..b36eff524d 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -78,14 +78,11 @@ XenGetE820Map (
> /**
> Connects to the Hypervisor.
>
> - @param XenLeaf CPUID index used to connect.
> -
> @return EFI_STATUS
>
> **/
> EFI_STATUS
> XenConnect (
> - UINT32 XenLeaf
> )
> {
> UINT32 Index;
> @@ -96,7 +93,13 @@ XenConnect (
> CHAR8 Sig[sizeof (Info->Signature) + 1];
> UINT32 *PVHResetVectorData;
>
> - AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
> + ASSERT (mXenLeaf != 0);
> +
> + //
> + // Prepare HyperPages to be able to make hypercalls
> + //
> +
> + AsmCpuid (mXenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
> mXenInfo.HyperPages = AllocatePages (TransferPages);
> if (!mXenInfo.HyperPages) {
> return EFI_OUT_OF_RESOURCES;
> @@ -108,7 +111,11 @@ XenConnect (
> (Index << EFI_PAGE_SHIFT) + Index);
> }
>
> - AsmCpuid (XenLeaf + 1, &XenVersion, NULL, NULL, NULL);
> + //
> + // Find out the Xen version
> + //
> +
> + AsmCpuid (mXenLeaf + 1, &XenVersion, NULL, NULL, NULL);
> DEBUG ((EFI_D_ERROR, "Detected Xen version %d.%d\n",
> XenVersion >> 16, XenVersion & 0xFFFF));
> mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
> @@ -265,12 +272,6 @@ InitializeXen (
> {
> RETURN_STATUS PcdStatus;
>
> - if (mXenLeaf == 0) {
> - return EFI_NOT_FOUND;
> - }
> -
> - XenConnect (mXenLeaf);
> -
> //
> // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
> // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
>
Acked-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 18/31] OvmfPkg/XenPlatformPei: Setup HyperPages earlier
@ 2019-04-12 9:17 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:17 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> 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().
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 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 5565d47e34..a524c23a43 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -85,6 +85,11 @@ InstallClearCacheCallback (
> VOID
> );
>
> +EFI_STATUS
> +XenConnect (
> + VOID
> + );
> +
> EFI_STATUS
> InitializeXen (
> VOID
> diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
> index 2d567a4760..5e6d553ad5 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -421,6 +421,8 @@ InitializeXenPlatform (
> CpuDeadLoop ();
> }
>
> + XenConnect ();
> +
> BootModeInitialization ();
> AddressWidthInitialization ();
>
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 22c7a22c88..b36eff524d 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -78,14 +78,11 @@ XenGetE820Map (
> /**
> Connects to the Hypervisor.
>
> - @param XenLeaf CPUID index used to connect.
> -
> @return EFI_STATUS
>
> **/
> EFI_STATUS
> XenConnect (
> - UINT32 XenLeaf
> )
> {
> UINT32 Index;
> @@ -96,7 +93,13 @@ XenConnect (
> CHAR8 Sig[sizeof (Info->Signature) + 1];
> UINT32 *PVHResetVectorData;
>
> - AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
> + ASSERT (mXenLeaf != 0);
> +
> + //
> + // Prepare HyperPages to be able to make hypercalls
> + //
> +
> + AsmCpuid (mXenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
> mXenInfo.HyperPages = AllocatePages (TransferPages);
> if (!mXenInfo.HyperPages) {
> return EFI_OUT_OF_RESOURCES;
> @@ -108,7 +111,11 @@ XenConnect (
> (Index << EFI_PAGE_SHIFT) + Index);
> }
>
> - AsmCpuid (XenLeaf + 1, &XenVersion, NULL, NULL, NULL);
> + //
> + // Find out the Xen version
> + //
> +
> + AsmCpuid (mXenLeaf + 1, &XenVersion, NULL, NULL, NULL);
> DEBUG ((EFI_D_ERROR, "Detected Xen version %d.%d\n",
> XenVersion >> 16, XenVersion & 0xFFFF));
> mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
> @@ -265,12 +272,6 @@ InitializeXen (
> {
> RETURN_STATUS PcdStatus;
>
> - if (mXenLeaf == 0) {
> - return EFI_NOT_FOUND;
> - }
> -
> - XenConnect (mXenLeaf);
> -
> //
> // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
> // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
>
Acked-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 19/31] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
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 a524c23a43..c5a139f016 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -105,6 +105,11 @@ XenHvmloaderDetected (
VOID
);
+BOOLEAN
+XenPvhDetected (
+ VOID
+ );
+
VOID
AmdSevInitialize (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index b36eff524d..23ff3102b5 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -217,6 +217,19 @@ XenHvmloaderDetected (
return (mXenHvmloaderInfo != NULL);
}
+BOOLEAN
+XenPvhDetected (
+ VOID
+ )
+{
+ //
+ // This function should only be used after XenConnect
+ //
+ ASSERT (mXenInfo.VersionMajor != 0);
+
+ return mXenHvmloaderInfo == NULL;
+}
+
VOID
XenPublishRamRegions (
VOID
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 19/31] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
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 a524c23a43..c5a139f016 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -105,6 +105,11 @@ XenHvmloaderDetected (
VOID
);
+BOOLEAN
+XenPvhDetected (
+ VOID
+ );
+
VOID
AmdSevInitialize (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index b36eff524d..23ff3102b5 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -217,6 +217,19 @@ XenHvmloaderDetected (
return (mXenHvmloaderInfo != NULL);
}
+BOOLEAN
+XenPvhDetected (
+ VOID
+ )
+{
+ //
+ // This function should only be used after XenConnect
+ //
+ ASSERT (mXenInfo.VersionMajor != 0);
+
+ return mXenHvmloaderInfo == NULL;
+}
+
VOID
XenPublishRamRegions (
VOID
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 19/31] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
@ 2019-04-12 9:20 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:20 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 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 a524c23a43..c5a139f016 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -105,6 +105,11 @@ XenHvmloaderDetected (
> VOID
> );
>
> +BOOLEAN
> +XenPvhDetected (
> + VOID
> + );
> +
> VOID
> AmdSevInitialize (
> VOID
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index b36eff524d..23ff3102b5 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -217,6 +217,19 @@ XenHvmloaderDetected (
> return (mXenHvmloaderInfo != NULL);
> }
>
> +BOOLEAN
> +XenPvhDetected (
> + VOID
> + )
> +{
> + //
> + // This function should only be used after XenConnect
> + //
> + ASSERT (mXenInfo.VersionMajor != 0);
> +
> + return mXenHvmloaderInfo == NULL;
> +}
> +
> VOID
> XenPublishRamRegions (
> VOID
>
(1) Please write a nonempty commit message body.
with that
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 19/31] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
@ 2019-04-12 9:20 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:20 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 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 a524c23a43..c5a139f016 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -105,6 +105,11 @@ XenHvmloaderDetected (
> VOID
> );
>
> +BOOLEAN
> +XenPvhDetected (
> + VOID
> + );
> +
> VOID
> AmdSevInitialize (
> VOID
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index b36eff524d..23ff3102b5 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -217,6 +217,19 @@ XenHvmloaderDetected (
> return (mXenHvmloaderInfo != NULL);
> }
>
> +BOOLEAN
> +XenPvhDetected (
> + VOID
> + )
> +{
> + //
> + // This function should only be used after XenConnect
> + //
> + ASSERT (mXenInfo.VersionMajor != 0);
> +
> + return mXenHvmloaderInfo == NULL;
> +}
> +
> VOID
> XenPublishRamRegions (
> VOID
>
(1) Please write a nonempty commit message body.
with that
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 20/31] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This is copied over from the public header of the Xen Project, with the
type name modified to build on OVMF.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
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 020155962c..b00a87097d 100644
--- a/OvmfPkg/Include/IndustryStandard/Xen/memory.h
+++ b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
@@ -81,6 +81,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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 20/31] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This is copied over from the public header of the Xen Project, with the
type name modified to build on OVMF.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
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 020155962c..b00a87097d 100644
--- a/OvmfPkg/Include/IndustryStandard/Xen/memory.h
+++ b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
@@ -81,6 +81,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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 20/31] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h
@ 2019-04-12 9:22 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:22 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This is copied over from the public header of the Xen Project, with the
(1) Please expand "This".
with that,
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
> type name modified to build on OVMF.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 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 020155962c..b00a87097d 100644
> --- a/OvmfPkg/Include/IndustryStandard/Xen/memory.h
> +++ b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
> @@ -81,6 +81,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__ */
>
> /*
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 20/31] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h
@ 2019-04-12 9:22 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:22 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This is copied over from the public header of the Xen Project, with the
(1) Please expand "This".
with that,
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
> type name modified to build on OVMF.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 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 020155962c..b00a87097d 100644
> --- a/OvmfPkg/Include/IndustryStandard/Xen/memory.h
> +++ b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
> @@ -81,6 +81,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__ */
>
> /*
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 21/31] OvmfPkg/XenPlatformPei: Get E820 table via hypercall ...
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
.. when hvmloader haven't runned before OVMF. The only way left to get
an E820 table is to ask Xen via an hypercall, the call can only be made
once so keep the result cached for later.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenPlatformPei/Xen.c | 46 +++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 23ff3102b5..f8cee671d8 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -33,6 +33,7 @@
#include <Library/MtrrLib.h>
#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
#include <Library/XenHypercallLib.h>
+#include <IndustryStandard/Xen/memory.h>
#include "Platform.h"
#include "Xen.h"
@@ -46,6 +47,8 @@ EFI_XEN_INFO mXenInfo;
// Only the E820 table is used by OVMF.
//
EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
+EFI_E820_ENTRY64 E820Entries[128];
+UINT32 E820EntriesCount;
/**
Returns E820 map provided by Xen
@@ -61,6 +64,12 @@ XenGetE820Map (
UINT32 *Count
)
{
+ INTN ReturnCode;
+ xen_memory_map_t Parameters;
+ UINTN LoopIndex;
+ UINTN Index;
+ EFI_E820_ENTRY64 TmpEntry;
+
//
// Get E820 produced by hvmloader
//
@@ -72,7 +81,42 @@ XenGetE820Map (
return EFI_SUCCESS;
}
- return EFI_NOT_FOUND;
+ //
+ // Otherwise, get the E820 table from the Xen hypervisor
+ //
+
+ if (E820EntriesCount > 0) {
+ *Entries = E820Entries;
+ *Count = E820EntriesCount;
+ return EFI_SUCCESS;
+ }
+
+ Parameters.nr_entries = 128;
+ set_xen_guest_handle (Parameters.buffer, E820Entries);
+
+ // Returns a errno
+ ReturnCode = XenHypercallMemoryOp (XENMEM_memory_map, &Parameters);
+ ASSERT (ReturnCode == 0);
+
+ E820EntriesCount = Parameters.nr_entries;
+
+ //
+ // Sort E820 entries
+ //
+ for (LoopIndex = 1; LoopIndex < E820EntriesCount; LoopIndex++) {
+ for (Index = LoopIndex; Index < E820EntriesCount; Index++) {
+ if (E820Entries[Index - 1].BaseAddr > E820Entries[Index].BaseAddr) {
+ TmpEntry = E820Entries[Index];
+ E820Entries[Index] = E820Entries[Index - 1];
+ E820Entries[Index - 1] = TmpEntry;
+ }
+ }
+ }
+
+ *Count = E820EntriesCount;
+ *Entries = E820Entries;
+
+ return EFI_SUCCESS;
}
/**
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 21/31] OvmfPkg/XenPlatformPei: Get E820 table via hypercall ...
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
.. when hvmloader haven't runned before OVMF. The only way left to get
an E820 table is to ask Xen via an hypercall, the call can only be made
once so keep the result cached for later.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenPlatformPei/Xen.c | 46 +++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 23ff3102b5..f8cee671d8 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -33,6 +33,7 @@
#include <Library/MtrrLib.h>
#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
#include <Library/XenHypercallLib.h>
+#include <IndustryStandard/Xen/memory.h>
#include "Platform.h"
#include "Xen.h"
@@ -46,6 +47,8 @@ EFI_XEN_INFO mXenInfo;
// Only the E820 table is used by OVMF.
//
EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
+EFI_E820_ENTRY64 E820Entries[128];
+UINT32 E820EntriesCount;
/**
Returns E820 map provided by Xen
@@ -61,6 +64,12 @@ XenGetE820Map (
UINT32 *Count
)
{
+ INTN ReturnCode;
+ xen_memory_map_t Parameters;
+ UINTN LoopIndex;
+ UINTN Index;
+ EFI_E820_ENTRY64 TmpEntry;
+
//
// Get E820 produced by hvmloader
//
@@ -72,7 +81,42 @@ XenGetE820Map (
return EFI_SUCCESS;
}
- return EFI_NOT_FOUND;
+ //
+ // Otherwise, get the E820 table from the Xen hypervisor
+ //
+
+ if (E820EntriesCount > 0) {
+ *Entries = E820Entries;
+ *Count = E820EntriesCount;
+ return EFI_SUCCESS;
+ }
+
+ Parameters.nr_entries = 128;
+ set_xen_guest_handle (Parameters.buffer, E820Entries);
+
+ // Returns a errno
+ ReturnCode = XenHypercallMemoryOp (XENMEM_memory_map, &Parameters);
+ ASSERT (ReturnCode == 0);
+
+ E820EntriesCount = Parameters.nr_entries;
+
+ //
+ // Sort E820 entries
+ //
+ for (LoopIndex = 1; LoopIndex < E820EntriesCount; LoopIndex++) {
+ for (Index = LoopIndex; Index < E820EntriesCount; Index++) {
+ if (E820Entries[Index - 1].BaseAddr > E820Entries[Index].BaseAddr) {
+ TmpEntry = E820Entries[Index];
+ E820Entries[Index] = E820Entries[Index - 1];
+ E820Entries[Index - 1] = TmpEntry;
+ }
+ }
+ }
+
+ *Count = E820EntriesCount;
+ *Entries = E820Entries;
+
+ return EFI_SUCCESS;
}
/**
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 21/31] OvmfPkg/XenPlatformPei: Get E820 table via hypercall ...
@ 2019-04-12 9:33 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:33 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> .. when hvmloader haven't runned before OVMF. The only way left to get
> an E820 table is to ask Xen via an hypercall, the call can only be made
> once so keep the result cached for later.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenPlatformPei/Xen.c | 46 +++++++++++++++++++-
> 1 file changed, 45 insertions(+), 1 deletion(-)
(1) Please change the subject to
OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall
(70 characters); and pls write a self-contained commit message body.
(2) s/haven't runned/hasn't run/
>
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 23ff3102b5..f8cee671d8 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -33,6 +33,7 @@
> #include <Library/MtrrLib.h>
> #include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
> #include <Library/XenHypercallLib.h>
> +#include <IndustryStandard/Xen/memory.h>
>
> #include "Platform.h"
> #include "Xen.h"
> @@ -46,6 +47,8 @@ EFI_XEN_INFO mXenInfo;
> // Only the E820 table is used by OVMF.
> //
> EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
> +EFI_E820_ENTRY64 E820Entries[128];
> +UINT32 E820EntriesCount;
(3) Please prefix both of these global variables with "m".
(I'd also recommend STATIC.)
>
> /**
> Returns E820 map provided by Xen
> @@ -61,6 +64,12 @@ XenGetE820Map (
> UINT32 *Count
> )
> {
> + INTN ReturnCode;
> + xen_memory_map_t Parameters;
> + UINTN LoopIndex;
> + UINTN Index;
> + EFI_E820_ENTRY64 TmpEntry;
> +
> //
> // Get E820 produced by hvmloader
> //
> @@ -72,7 +81,42 @@ XenGetE820Map (
> return EFI_SUCCESS;
> }
>
> - return EFI_NOT_FOUND;
> + //
> + // Otherwise, get the E820 table from the Xen hypervisor
> + //
> +
> + if (E820EntriesCount > 0) {
> + *Entries = E820Entries;
> + *Count = E820EntriesCount;
> + return EFI_SUCCESS;
> + }
> +
> + Parameters.nr_entries = 128;
> + set_xen_guest_handle (Parameters.buffer, E820Entries);
> +
> + // Returns a errno
> + ReturnCode = XenHypercallMemoryOp (XENMEM_memory_map, &Parameters);
> + ASSERT (ReturnCode == 0);
> +
> + E820EntriesCount = Parameters.nr_entries;
> +
> + //
> + // Sort E820 entries
> + //
> + for (LoopIndex = 1; LoopIndex < E820EntriesCount; LoopIndex++) {
> + for (Index = LoopIndex; Index < E820EntriesCount; Index++) {
> + if (E820Entries[Index - 1].BaseAddr > E820Entries[Index].BaseAddr) {
> + TmpEntry = E820Entries[Index];
> + E820Entries[Index] = E820Entries[Index - 1];
> + E820Entries[Index - 1] = TmpEntry;
> + }
> + }
> + }
> +
> + *Count = E820EntriesCount;
> + *Entries = E820Entries;
> +
> + return EFI_SUCCESS;
> }
>
> /**
>
"xen_memory_map_t" and "set_xen_guest_handle" look really foreign in edk2, but I guess we'll have to live with them.
With (1) through (3) updated:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 21/31] OvmfPkg/XenPlatformPei: Get E820 table via hypercall ...
@ 2019-04-12 9:33 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 9:33 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> .. when hvmloader haven't runned before OVMF. The only way left to get
> an E820 table is to ask Xen via an hypercall, the call can only be made
> once so keep the result cached for later.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenPlatformPei/Xen.c | 46 +++++++++++++++++++-
> 1 file changed, 45 insertions(+), 1 deletion(-)
(1) Please change the subject to
OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall
(70 characters); and pls write a self-contained commit message body.
(2) s/haven't runned/hasn't run/
>
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 23ff3102b5..f8cee671d8 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -33,6 +33,7 @@
> #include <Library/MtrrLib.h>
> #include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
> #include <Library/XenHypercallLib.h>
> +#include <IndustryStandard/Xen/memory.h>
>
> #include "Platform.h"
> #include "Xen.h"
> @@ -46,6 +47,8 @@ EFI_XEN_INFO mXenInfo;
> // Only the E820 table is used by OVMF.
> //
> EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
> +EFI_E820_ENTRY64 E820Entries[128];
> +UINT32 E820EntriesCount;
(3) Please prefix both of these global variables with "m".
(I'd also recommend STATIC.)
>
> /**
> Returns E820 map provided by Xen
> @@ -61,6 +64,12 @@ XenGetE820Map (
> UINT32 *Count
> )
> {
> + INTN ReturnCode;
> + xen_memory_map_t Parameters;
> + UINTN LoopIndex;
> + UINTN Index;
> + EFI_E820_ENTRY64 TmpEntry;
> +
> //
> // Get E820 produced by hvmloader
> //
> @@ -72,7 +81,42 @@ XenGetE820Map (
> return EFI_SUCCESS;
> }
>
> - return EFI_NOT_FOUND;
> + //
> + // Otherwise, get the E820 table from the Xen hypervisor
> + //
> +
> + if (E820EntriesCount > 0) {
> + *Entries = E820Entries;
> + *Count = E820EntriesCount;
> + return EFI_SUCCESS;
> + }
> +
> + Parameters.nr_entries = 128;
> + set_xen_guest_handle (Parameters.buffer, E820Entries);
> +
> + // Returns a errno
> + ReturnCode = XenHypercallMemoryOp (XENMEM_memory_map, &Parameters);
> + ASSERT (ReturnCode == 0);
> +
> + E820EntriesCount = Parameters.nr_entries;
> +
> + //
> + // Sort E820 entries
> + //
> + for (LoopIndex = 1; LoopIndex < E820EntriesCount; LoopIndex++) {
> + for (Index = LoopIndex; Index < E820EntriesCount; Index++) {
> + if (E820Entries[Index - 1].BaseAddr > E820Entries[Index].BaseAddr) {
> + TmpEntry = E820Entries[Index];
> + E820Entries[Index] = E820Entries[Index - 1];
> + E820Entries[Index - 1] = TmpEntry;
> + }
> + }
> + }
> +
> + *Count = E820EntriesCount;
> + *Entries = E820Entries;
> +
> + return EFI_SUCCESS;
> }
>
> /**
>
"xen_memory_map_t" and "set_xen_guest_handle" look really foreign in edk2, but I guess we'll have to live with them.
With (1) through (3) updated:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 21/31] OvmfPkg/XenPlatformPei: Get E820 table via hypercall ...
@ 2019-04-12 9:45 ` Andrew Cooper
0 siblings, 0 replies; 168+ messages in thread
From: Andrew Cooper @ 2019-04-12 9:45 UTC (permalink / raw)
To: Laszlo Ersek, devel, anthony.perard
Cc: Jordan Justen, Julien Grall, Ard Biesheuvel, xen-devel
On 12/04/2019 10:33, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> @@ -72,7 +81,42 @@ XenGetE820Map (
>> return EFI_SUCCESS;
>> }
>>
>> - return EFI_NOT_FOUND;
>> + //
>> + // Otherwise, get the E820 table from the Xen hypervisor
>> + //
>> +
>> + if (E820EntriesCount > 0) {
>> + *Entries = E820Entries;
>> + *Count = E820EntriesCount;
>> + return EFI_SUCCESS;
>> + }
>> +
>> + Parameters.nr_entries = 128;
>> + set_xen_guest_handle (Parameters.buffer, E820Entries);
>> +
>> + // Returns a errno
>> + ReturnCode = XenHypercallMemoryOp (XENMEM_memory_map, &Parameters);
>> + ASSERT (ReturnCode == 0);
>> +
>> + E820EntriesCount = Parameters.nr_entries;
>> +
>> + //
>> + // Sort E820 entries
>> + //
>> + for (LoopIndex = 1; LoopIndex < E820EntriesCount; LoopIndex++) {
>> + for (Index = LoopIndex; Index < E820EntriesCount; Index++) {
>> + if (E820Entries[Index - 1].BaseAddr > E820Entries[Index].BaseAddr) {
>> + TmpEntry = E820Entries[Index];
>> + E820Entries[Index] = E820Entries[Index - 1];
>> + E820Entries[Index - 1] = TmpEntry;
>> + }
>> + }
>> + }
>> +
>> + *Count = E820EntriesCount;
>> + *Entries = E820Entries;
>> +
>> + return EFI_SUCCESS;
>> }
>>
>> /**
>>
> "xen_memory_map_t" and "set_xen_guest_handle" look really foreign in edk2, but I guess we'll have to live with them.
For historical reasons, the ABI was described using C structures (and in
hindsight, a very poor idea, seeing as it all went to pot when "unsigned
long" changed size for 64bit), and the expectation was that every
downstream project wanting to make hypercalls would copy the "canonical
copy" of the ABI, which turns it into a defacto API as well.
However, there is absolutely nothing stopping a downstream project
deciding not to take this route, and having Xen's ABI expressed in their
local style. Ultimately, that is down to the maintainers of the project
to decide which approach they would prefer.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 21/31] OvmfPkg/XenPlatformPei: Get E820 table via hypercall ...
@ 2019-04-12 9:45 ` Andrew Cooper
0 siblings, 0 replies; 168+ messages in thread
From: Andrew Cooper @ 2019-04-12 9:45 UTC (permalink / raw)
To: Laszlo Ersek, devel, anthony.perard
Cc: Jordan Justen, Julien Grall, Ard Biesheuvel, xen-devel
On 12/04/2019 10:33, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> @@ -72,7 +81,42 @@ XenGetE820Map (
>> return EFI_SUCCESS;
>> }
>>
>> - return EFI_NOT_FOUND;
>> + //
>> + // Otherwise, get the E820 table from the Xen hypervisor
>> + //
>> +
>> + if (E820EntriesCount > 0) {
>> + *Entries = E820Entries;
>> + *Count = E820EntriesCount;
>> + return EFI_SUCCESS;
>> + }
>> +
>> + Parameters.nr_entries = 128;
>> + set_xen_guest_handle (Parameters.buffer, E820Entries);
>> +
>> + // Returns a errno
>> + ReturnCode = XenHypercallMemoryOp (XENMEM_memory_map, &Parameters);
>> + ASSERT (ReturnCode == 0);
>> +
>> + E820EntriesCount = Parameters.nr_entries;
>> +
>> + //
>> + // Sort E820 entries
>> + //
>> + for (LoopIndex = 1; LoopIndex < E820EntriesCount; LoopIndex++) {
>> + for (Index = LoopIndex; Index < E820EntriesCount; Index++) {
>> + if (E820Entries[Index - 1].BaseAddr > E820Entries[Index].BaseAddr) {
>> + TmpEntry = E820Entries[Index];
>> + E820Entries[Index] = E820Entries[Index - 1];
>> + E820Entries[Index - 1] = TmpEntry;
>> + }
>> + }
>> + }
>> +
>> + *Count = E820EntriesCount;
>> + *Entries = E820Entries;
>> +
>> + return EFI_SUCCESS;
>> }
>>
>> /**
>>
> "xen_memory_map_t" and "set_xen_guest_handle" look really foreign in edk2, but I guess we'll have to live with them.
For historical reasons, the ABI was described using C structures (and in
hindsight, a very poor idea, seeing as it all went to pot when "unsigned
long" changed size for 64bit), and the expectation was that every
downstream project wanting to make hypercalls would copy the "canonical
copy" of the ABI, which turns it into a defacto API as well.
However, there is absolutely nothing stopping a downstream project
deciding not to take this route, and having Xen's ABI expressed in their
local style. Ultimately, that is down to the maintainers of the project
to decide which approach they would prefer.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 22/31] OvmfPkg/XenPlatformPei: Rework memory detection
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
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
works without CMOS by reading the e820 table.
Rework XenPublishRamRegions for PVH, handle the Reserve type and explain
about the ACPI type. MTRR settings aren't modified anymore, on HVM, it's
already done by hvmloader, on PVH it is supposed to have sane default.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
About MTRR, should we redo the setting in OVMF? Even if in both case of
PVH and HVM, something would have setup the default type to write back
and handle a few other ranges like PCI hole, hvmloader for HVM or and
libxc I think for PVH.
(For PVH, it's in the spec as well
https://xenbits.xenproject.org/docs/unstable/misc/pvh.html#mtrr )
OvmfPkg/XenPlatformPei/Platform.h | 6 ++
OvmfPkg/XenPlatformPei/MemDetect.c | 71 ++++++++++++++++++++
OvmfPkg/XenPlatformPei/Xen.c | 47 +++++++++----
3 files changed, 111 insertions(+), 13 deletions(-)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
index c5a139f016..d6d93eab2d 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -120,6 +120,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 db3d387d1c..0c066d518b 100644
--- a/OvmfPkg/XenPlatformPei/MemDetect.c
+++ b/OvmfPkg/XenPlatformPei/MemDetect.c
@@ -102,6 +102,47 @@ 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 (&E820Map, &E820EntriesCount);
+ 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.
+ //
+ HighestAddress &= ~(UINT64)EFI_PAGE_MASK;
+
+ return HighestAddress;
+}
UINT32
GetSystemMemorySizeBelow4gb (
@@ -111,6 +152,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
@@ -135,6 +189,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 4GB MB.
// * CMOS(0x5d) is the most significant size byte
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index f8cee671d8..7b503f2c4e 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -282,6 +282,8 @@ XenPublishRamRegions (
EFI_E820_ENTRY64 *E820Map;
UINT32 E820EntriesCount;
EFI_STATUS Status;
+ EFI_E820_ENTRY64 *Entry;
+ UINTN Index;
DEBUG ((EFI_D_INFO, "Using memory map provided by Xen\n"));
@@ -290,26 +292,45 @@ XenPublishRamRegions (
//
E820EntriesCount = 0;
Status = XenGetE820Map (&E820Map, &E820EntriesCount);
-
ASSERT_EFI_ERROR (Status);
- if (E820EntriesCount > 0) {
- EFI_E820_ENTRY64 *Entry;
- UINT32 Loop;
+ for (Index = 0; Index < E820EntriesCount; Index++) {
+ UINT64 Base;
+ UINT64 End;
- for (Loop = 0; Loop < E820EntriesCount; Loop++) {
- Entry = E820Map + Loop;
+ Entry = &E820Map[Index];
+
+ //
+ // Round up the start address, and round down the end address.
+ //
+ Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
+ End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
+
+ switch (Entry->Type) {
+ case EfiAcpiAddressRangeMemory:
+ AddMemoryRangeHob (Base, End);
+ break;
+ case EfiAcpiAddressRangeACPI:
+ //
+ // Ignore, OVMF should read the ACPI tables and provide them to linux
+ // from a different location.
+ //
+ break;
+ case EfiAcpiAddressRangeReserved:
//
- // Only care about RAM
+ // Avoid ranges marked as reserved in the e820 table provided by
+ // hvmloader as it conflicts with an other aperture.
+ // error message: CpuDxe: IntersectMemoryDescriptor:
+ // desc [FC000000, 100000000) type 1 cap 8700000000026001
+ // conflicts with aperture [FEE00000, FEE01000) cap 1
//
- if (Entry->Type != EfiAcpiAddressRangeMemory) {
- continue;
+ if (!XenHvmloaderDetected ()) {
+ AddReservedMemoryBaseSizeHob (Base, End - Base, FALSE);
}
-
- AddMemoryBaseSizeHob (Entry->BaseAddr, Entry->Length);
-
- MtrrSetMemoryAttribute (Entry->BaseAddr, Entry->Length, CacheWriteBack);
+ break;
+ default:
+ break;
}
}
}
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 22/31] OvmfPkg/XenPlatformPei: Rework memory detection
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
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
works without CMOS by reading the e820 table.
Rework XenPublishRamRegions for PVH, handle the Reserve type and explain
about the ACPI type. MTRR settings aren't modified anymore, on HVM, it's
already done by hvmloader, on PVH it is supposed to have sane default.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
About MTRR, should we redo the setting in OVMF? Even if in both case of
PVH and HVM, something would have setup the default type to write back
and handle a few other ranges like PCI hole, hvmloader for HVM or and
libxc I think for PVH.
(For PVH, it's in the spec as well
https://xenbits.xenproject.org/docs/unstable/misc/pvh.html#mtrr )
OvmfPkg/XenPlatformPei/Platform.h | 6 ++
OvmfPkg/XenPlatformPei/MemDetect.c | 71 ++++++++++++++++++++
OvmfPkg/XenPlatformPei/Xen.c | 47 +++++++++----
3 files changed, 111 insertions(+), 13 deletions(-)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
index c5a139f016..d6d93eab2d 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -120,6 +120,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 db3d387d1c..0c066d518b 100644
--- a/OvmfPkg/XenPlatformPei/MemDetect.c
+++ b/OvmfPkg/XenPlatformPei/MemDetect.c
@@ -102,6 +102,47 @@ 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 (&E820Map, &E820EntriesCount);
+ 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.
+ //
+ HighestAddress &= ~(UINT64)EFI_PAGE_MASK;
+
+ return HighestAddress;
+}
UINT32
GetSystemMemorySizeBelow4gb (
@@ -111,6 +152,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
@@ -135,6 +189,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 4GB MB.
// * CMOS(0x5d) is the most significant size byte
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index f8cee671d8..7b503f2c4e 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -282,6 +282,8 @@ XenPublishRamRegions (
EFI_E820_ENTRY64 *E820Map;
UINT32 E820EntriesCount;
EFI_STATUS Status;
+ EFI_E820_ENTRY64 *Entry;
+ UINTN Index;
DEBUG ((EFI_D_INFO, "Using memory map provided by Xen\n"));
@@ -290,26 +292,45 @@ XenPublishRamRegions (
//
E820EntriesCount = 0;
Status = XenGetE820Map (&E820Map, &E820EntriesCount);
-
ASSERT_EFI_ERROR (Status);
- if (E820EntriesCount > 0) {
- EFI_E820_ENTRY64 *Entry;
- UINT32 Loop;
+ for (Index = 0; Index < E820EntriesCount; Index++) {
+ UINT64 Base;
+ UINT64 End;
- for (Loop = 0; Loop < E820EntriesCount; Loop++) {
- Entry = E820Map + Loop;
+ Entry = &E820Map[Index];
+
+ //
+ // Round up the start address, and round down the end address.
+ //
+ Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
+ End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
+
+ switch (Entry->Type) {
+ case EfiAcpiAddressRangeMemory:
+ AddMemoryRangeHob (Base, End);
+ break;
+ case EfiAcpiAddressRangeACPI:
+ //
+ // Ignore, OVMF should read the ACPI tables and provide them to linux
+ // from a different location.
+ //
+ break;
+ case EfiAcpiAddressRangeReserved:
//
- // Only care about RAM
+ // Avoid ranges marked as reserved in the e820 table provided by
+ // hvmloader as it conflicts with an other aperture.
+ // error message: CpuDxe: IntersectMemoryDescriptor:
+ // desc [FC000000, 100000000) type 1 cap 8700000000026001
+ // conflicts with aperture [FEE00000, FEE01000) cap 1
//
- if (Entry->Type != EfiAcpiAddressRangeMemory) {
- continue;
+ if (!XenHvmloaderDetected ()) {
+ AddReservedMemoryBaseSizeHob (Base, End - Base, FALSE);
}
-
- AddMemoryBaseSizeHob (Entry->BaseAddr, Entry->Length);
-
- MtrrSetMemoryAttribute (Entry->BaseAddr, Entry->Length, CacheWriteBack);
+ break;
+ default:
+ break;
}
}
}
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 22/31] OvmfPkg/XenPlatformPei: Rework memory detection
@ 2019-04-12 11:15 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 11:15 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> 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
> works without CMOS by reading the e820 table.
>
> Rework XenPublishRamRegions for PVH, handle the Reserve type and explain
> about the ACPI type. MTRR settings aren't modified anymore, on HVM, it's
> already done by hvmloader, on PVH it is supposed to have sane default.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
For this patch:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Another comment below:
>
> Notes:
> About MTRR, should we redo the setting in OVMF? Even if in both case of
> PVH and HVM, something would have setup the default type to write back
> and handle a few other ranges like PCI hole, hvmloader for HVM or and
> libxc I think for PVH.
This patch is *exactly* the kind of change that I want to keep as far as
possible away from code that runs (even if in part) on QEMU. Every time
I need to touch OvmfPkg/PlatformPei/MemDetect.c, and in particular go
near the MTRR setup or the physical memory layout (resource descriptor
HOBs, CPU address width, etc), I start convulsing.
If, under "OvmfPkg/PlatformPei/", you could limit your changes to
"Xen.c", I'd be OK with that. Otherwise, please don't go near that code.
Again, this is *the* kind of change why we have the platform split /
duplication.
Thanks
Laszlo
>
> (For PVH, it's in the spec as well
> https://xenbits.xenproject.org/docs/unstable/misc/pvh.html#mtrr )
>
> OvmfPkg/XenPlatformPei/Platform.h | 6 ++
> OvmfPkg/XenPlatformPei/MemDetect.c | 71 ++++++++++++++++++++
> OvmfPkg/XenPlatformPei/Xen.c | 47 +++++++++----
> 3 files changed, 111 insertions(+), 13 deletions(-)
>
> diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
> index c5a139f016..d6d93eab2d 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -120,6 +120,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 db3d387d1c..0c066d518b 100644
> --- a/OvmfPkg/XenPlatformPei/MemDetect.c
> +++ b/OvmfPkg/XenPlatformPei/MemDetect.c
> @@ -102,6 +102,47 @@ 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 (&E820Map, &E820EntriesCount);
> + 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.
> + //
> + HighestAddress &= ~(UINT64)EFI_PAGE_MASK;
> +
> + return HighestAddress;
> +}
>
> UINT32
> GetSystemMemorySizeBelow4gb (
> @@ -111,6 +152,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
> @@ -135,6 +189,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 4GB MB.
> // * CMOS(0x5d) is the most significant size byte
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index f8cee671d8..7b503f2c4e 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -282,6 +282,8 @@ XenPublishRamRegions (
> EFI_E820_ENTRY64 *E820Map;
> UINT32 E820EntriesCount;
> EFI_STATUS Status;
> + EFI_E820_ENTRY64 *Entry;
> + UINTN Index;
>
> DEBUG ((EFI_D_INFO, "Using memory map provided by Xen\n"));
>
> @@ -290,26 +292,45 @@ XenPublishRamRegions (
> //
> E820EntriesCount = 0;
> Status = XenGetE820Map (&E820Map, &E820EntriesCount);
> -
> ASSERT_EFI_ERROR (Status);
>
> - if (E820EntriesCount > 0) {
> - EFI_E820_ENTRY64 *Entry;
> - UINT32 Loop;
> + for (Index = 0; Index < E820EntriesCount; Index++) {
> + UINT64 Base;
> + UINT64 End;
>
> - for (Loop = 0; Loop < E820EntriesCount; Loop++) {
> - Entry = E820Map + Loop;
> + Entry = &E820Map[Index];
>
> +
> + //
> + // Round up the start address, and round down the end address.
> + //
> + Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
> + End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
> +
> + switch (Entry->Type) {
> + case EfiAcpiAddressRangeMemory:
> + AddMemoryRangeHob (Base, End);
> + break;
> + case EfiAcpiAddressRangeACPI:
> + //
> + // Ignore, OVMF should read the ACPI tables and provide them to linux
> + // from a different location.
> + //
> + break;
> + case EfiAcpiAddressRangeReserved:
> //
> - // Only care about RAM
> + // Avoid ranges marked as reserved in the e820 table provided by
> + // hvmloader as it conflicts with an other aperture.
> + // error message: CpuDxe: IntersectMemoryDescriptor:
> + // desc [FC000000, 100000000) type 1 cap 8700000000026001
> + // conflicts with aperture [FEE00000, FEE01000) cap 1
> //
> - if (Entry->Type != EfiAcpiAddressRangeMemory) {
> - continue;
> + if (!XenHvmloaderDetected ()) {
> + AddReservedMemoryBaseSizeHob (Base, End - Base, FALSE);
> }
> -
> - AddMemoryBaseSizeHob (Entry->BaseAddr, Entry->Length);
> -
> - MtrrSetMemoryAttribute (Entry->BaseAddr, Entry->Length, CacheWriteBack);
> + break;
> + default:
> + break;
> }
> }
> }
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 22/31] OvmfPkg/XenPlatformPei: Rework memory detection
@ 2019-04-12 11:15 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-12 11:15 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> 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
> works without CMOS by reading the e820 table.
>
> Rework XenPublishRamRegions for PVH, handle the Reserve type and explain
> about the ACPI type. MTRR settings aren't modified anymore, on HVM, it's
> already done by hvmloader, on PVH it is supposed to have sane default.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
For this patch:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Another comment below:
>
> Notes:
> About MTRR, should we redo the setting in OVMF? Even if in both case of
> PVH and HVM, something would have setup the default type to write back
> and handle a few other ranges like PCI hole, hvmloader for HVM or and
> libxc I think for PVH.
This patch is *exactly* the kind of change that I want to keep as far as
possible away from code that runs (even if in part) on QEMU. Every time
I need to touch OvmfPkg/PlatformPei/MemDetect.c, and in particular go
near the MTRR setup or the physical memory layout (resource descriptor
HOBs, CPU address width, etc), I start convulsing.
If, under "OvmfPkg/PlatformPei/", you could limit your changes to
"Xen.c", I'd be OK with that. Otherwise, please don't go near that code.
Again, this is *the* kind of change why we have the platform split /
duplication.
Thanks
Laszlo
>
> (For PVH, it's in the spec as well
> https://xenbits.xenproject.org/docs/unstable/misc/pvh.html#mtrr )
>
> OvmfPkg/XenPlatformPei/Platform.h | 6 ++
> OvmfPkg/XenPlatformPei/MemDetect.c | 71 ++++++++++++++++++++
> OvmfPkg/XenPlatformPei/Xen.c | 47 +++++++++----
> 3 files changed, 111 insertions(+), 13 deletions(-)
>
> diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
> index c5a139f016..d6d93eab2d 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -120,6 +120,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 db3d387d1c..0c066d518b 100644
> --- a/OvmfPkg/XenPlatformPei/MemDetect.c
> +++ b/OvmfPkg/XenPlatformPei/MemDetect.c
> @@ -102,6 +102,47 @@ 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 (&E820Map, &E820EntriesCount);
> + 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.
> + //
> + HighestAddress &= ~(UINT64)EFI_PAGE_MASK;
> +
> + return HighestAddress;
> +}
>
> UINT32
> GetSystemMemorySizeBelow4gb (
> @@ -111,6 +152,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
> @@ -135,6 +189,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 4GB MB.
> // * CMOS(0x5d) is the most significant size byte
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index f8cee671d8..7b503f2c4e 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -282,6 +282,8 @@ XenPublishRamRegions (
> EFI_E820_ENTRY64 *E820Map;
> UINT32 E820EntriesCount;
> EFI_STATUS Status;
> + EFI_E820_ENTRY64 *Entry;
> + UINTN Index;
>
> DEBUG ((EFI_D_INFO, "Using memory map provided by Xen\n"));
>
> @@ -290,26 +292,45 @@ XenPublishRamRegions (
> //
> E820EntriesCount = 0;
> Status = XenGetE820Map (&E820Map, &E820EntriesCount);
> -
> ASSERT_EFI_ERROR (Status);
>
> - if (E820EntriesCount > 0) {
> - EFI_E820_ENTRY64 *Entry;
> - UINT32 Loop;
> + for (Index = 0; Index < E820EntriesCount; Index++) {
> + UINT64 Base;
> + UINT64 End;
>
> - for (Loop = 0; Loop < E820EntriesCount; Loop++) {
> - Entry = E820Map + Loop;
> + Entry = &E820Map[Index];
>
> +
> + //
> + // Round up the start address, and round down the end address.
> + //
> + Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
> + End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
> +
> + switch (Entry->Type) {
> + case EfiAcpiAddressRangeMemory:
> + AddMemoryRangeHob (Base, End);
> + break;
> + case EfiAcpiAddressRangeACPI:
> + //
> + // Ignore, OVMF should read the ACPI tables and provide them to linux
> + // from a different location.
> + //
> + break;
> + case EfiAcpiAddressRangeReserved:
> //
> - // Only care about RAM
> + // Avoid ranges marked as reserved in the e820 table provided by
> + // hvmloader as it conflicts with an other aperture.
> + // error message: CpuDxe: IntersectMemoryDescriptor:
> + // desc [FC000000, 100000000) type 1 cap 8700000000026001
> + // conflicts with aperture [FEE00000, FEE01000) cap 1
> //
> - if (Entry->Type != EfiAcpiAddressRangeMemory) {
> - continue;
> + if (!XenHvmloaderDetected ()) {
> + AddReservedMemoryBaseSizeHob (Base, End - Base, FALSE);
> }
> -
> - AddMemoryBaseSizeHob (Entry->BaseAddr, Entry->Length);
> -
> - MtrrSetMemoryAttribute (Entry->BaseAddr, Entry->Length, CacheWriteBack);
> + break;
> + default:
> + break;
> }
> }
> }
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 22/31] OvmfPkg/XenPlatformPei: Rework memory detection
@ 2019-04-15 13:42 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-15 13:42 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Jordan Justen, devel, xen-devel, Julien Grall, Ard Biesheuvel
On Fri, Apr 12, 2019 at 01:15:48PM +0200, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
> > Rework XenPublishRamRegions for PVH, handle the Reserve type and explain
> > about the ACPI type. MTRR settings aren't modified anymore, on HVM, it's
> > already done by hvmloader, on PVH it is supposed to have sane default.
> > ---
> > Notes:
> > About MTRR, should we redo the setting in OVMF? Even if in both case of
> > PVH and HVM, something would have setup the default type to write back
> > and handle a few other ranges like PCI hole, hvmloader for HVM or and
> > libxc I think for PVH.
>
> This patch is *exactly* the kind of change that I want to keep as far as
> possible away from code that runs (even if in part) on QEMU. Every time
> I need to touch OvmfPkg/PlatformPei/MemDetect.c, and in particular go
> near the MTRR setup or the physical memory layout (resource descriptor
> HOBs, CPU address width, etc), I start convulsing.
Sorry to have cause you fear. I wasn't suggesting to make changes to
code that can run on something else than Xen. That notes was really
about code that only run on Xen, because the patch removes one thing
that OVMF do on Xen, a MtrrSetMemoryAttribute(). Also, I'll need to have
Xen-folks to answer the question.
> If, under "OvmfPkg/PlatformPei/", you could limit your changes to
> "Xen.c", I'd be OK with that. Otherwise, please don't go near that code.
Changes would be limited to XenPlatformPei, I wouldn't need to change
the code that runs on QEMU.
> Again, this is *the* kind of change why we have the platform split /
> duplication.
I'm glad it's useful to have a separated XenPlatformPei module.
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v2 22/31] OvmfPkg/XenPlatformPei: Rework memory detection
@ 2019-04-15 13:42 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-15 13:42 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Jordan Justen, devel, xen-devel, Julien Grall, Ard Biesheuvel
On Fri, Apr 12, 2019 at 01:15:48PM +0200, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
> > Rework XenPublishRamRegions for PVH, handle the Reserve type and explain
> > about the ACPI type. MTRR settings aren't modified anymore, on HVM, it's
> > already done by hvmloader, on PVH it is supposed to have sane default.
> > ---
> > Notes:
> > About MTRR, should we redo the setting in OVMF? Even if in both case of
> > PVH and HVM, something would have setup the default type to write back
> > and handle a few other ranges like PCI hole, hvmloader for HVM or and
> > libxc I think for PVH.
>
> This patch is *exactly* the kind of change that I want to keep as far as
> possible away from code that runs (even if in part) on QEMU. Every time
> I need to touch OvmfPkg/PlatformPei/MemDetect.c, and in particular go
> near the MTRR setup or the physical memory layout (resource descriptor
> HOBs, CPU address width, etc), I start convulsing.
Sorry to have cause you fear. I wasn't suggesting to make changes to
code that can run on something else than Xen. That notes was really
about code that only run on Xen, because the patch removes one thing
that OVMF do on Xen, a MtrrSetMemoryAttribute(). Also, I'll need to have
Xen-folks to answer the question.
> If, under "OvmfPkg/PlatformPei/", you could limit your changes to
> "Xen.c", I'd be OK with that. Otherwise, please don't go near that code.
Changes would be limited to XenPlatformPei, I wouldn't need to change
the code that runs on QEMU.
> Again, this is *the* kind of change why we have the platform split /
> duplication.
I'm glad it's useful to have a separated XenPlatformPei module.
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 23/31] OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Linux panic if this region isn't reserved.
When Linux is booted on EFI system, it expects the memory at 0xa0000 to
_not_ be conventional memory. Otherwise a variable isn't initialised
properly and Linux panic when a virtual console/terminal is asked to be
created.
See for more detail:
https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02139.html
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenPlatformPei/Xen.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 7b503f2c4e..25f12c2f9c 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -294,6 +294,12 @@ XenPublishRamRegions (
Status = XenGetE820Map (&E820Map, &E820EntriesCount);
ASSERT_EFI_ERROR (Status);
+ AddMemoryBaseSizeHob (0, 0xA0000);
+ //
+ // Video memory + Legacy BIOS region, to allow Linux to boot.
+ //
+ AddReservedMemoryBaseSizeHob (0xA0000, BASE_1MB - 0xA0000, TRUE);
+
for (Index = 0; Index < E820EntriesCount; Index++) {
UINT64 Base;
UINT64 End;
@@ -307,6 +313,16 @@ XenPublishRamRegions (
Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
+ //
+ // Ignore the first 1MB, this is handled before the loop.
+ //
+ if (Base < BASE_1MB) {
+ Base = BASE_1MB;
+ }
+ if (Base >= End) {
+ continue;
+ }
+
switch (Entry->Type) {
case EfiAcpiAddressRangeMemory:
AddMemoryRangeHob (Base, End);
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 23/31] OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Linux panic if this region isn't reserved.
When Linux is booted on EFI system, it expects the memory at 0xa0000 to
_not_ be conventional memory. Otherwise a variable isn't initialised
properly and Linux panic when a virtual console/terminal is asked to be
created.
See for more detail:
https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02139.html
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenPlatformPei/Xen.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 7b503f2c4e..25f12c2f9c 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -294,6 +294,12 @@ XenPublishRamRegions (
Status = XenGetE820Map (&E820Map, &E820EntriesCount);
ASSERT_EFI_ERROR (Status);
+ AddMemoryBaseSizeHob (0, 0xA0000);
+ //
+ // Video memory + Legacy BIOS region, to allow Linux to boot.
+ //
+ AddReservedMemoryBaseSizeHob (0xA0000, BASE_1MB - 0xA0000, TRUE);
+
for (Index = 0; Index < E820EntriesCount; Index++) {
UINT64 Base;
UINT64 End;
@@ -307,6 +313,16 @@ XenPublishRamRegions (
Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
+ //
+ // Ignore the first 1MB, this is handled before the loop.
+ //
+ if (Base < BASE_1MB) {
+ Base = BASE_1MB;
+ }
+ if (Base >= End) {
+ continue;
+ }
+
switch (Entry->Type) {
case EfiAcpiAddressRangeMemory:
AddMemoryRangeHob (Base, End);
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 23/31] OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux
@ 2019-04-15 13:21 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:21 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Linux panic if this region isn't reserved.
Please expand "this" (just copy from the subject).
with that,
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
>
> When Linux is booted on EFI system, it expects the memory at 0xa0000 to
> _not_ be conventional memory. Otherwise a variable isn't initialised
> properly and Linux panic when a virtual console/terminal is asked to be
> created.
>
> See for more detail:
> https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02139.html
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenPlatformPei/Xen.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 7b503f2c4e..25f12c2f9c 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -294,6 +294,12 @@ XenPublishRamRegions (
> Status = XenGetE820Map (&E820Map, &E820EntriesCount);
> ASSERT_EFI_ERROR (Status);
>
> + AddMemoryBaseSizeHob (0, 0xA0000);
> + //
> + // Video memory + Legacy BIOS region, to allow Linux to boot.
> + //
> + AddReservedMemoryBaseSizeHob (0xA0000, BASE_1MB - 0xA0000, TRUE);
> +
> for (Index = 0; Index < E820EntriesCount; Index++) {
> UINT64 Base;
> UINT64 End;
> @@ -307,6 +313,16 @@ XenPublishRamRegions (
> Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
> End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
>
> + //
> + // Ignore the first 1MB, this is handled before the loop.
> + //
> + if (Base < BASE_1MB) {
> + Base = BASE_1MB;
> + }
> + if (Base >= End) {
> + continue;
> + }
> +
> switch (Entry->Type) {
> case EfiAcpiAddressRangeMemory:
> AddMemoryRangeHob (Base, End);
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 23/31] OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux
@ 2019-04-15 13:21 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:21 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> Linux panic if this region isn't reserved.
Please expand "this" (just copy from the subject).
with that,
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
>
> When Linux is booted on EFI system, it expects the memory at 0xa0000 to
> _not_ be conventional memory. Otherwise a variable isn't initialised
> properly and Linux panic when a virtual console/terminal is asked to be
> created.
>
> See for more detail:
> https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02139.html
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenPlatformPei/Xen.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 7b503f2c4e..25f12c2f9c 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -294,6 +294,12 @@ XenPublishRamRegions (
> Status = XenGetE820Map (&E820Map, &E820EntriesCount);
> ASSERT_EFI_ERROR (Status);
>
> + AddMemoryBaseSizeHob (0, 0xA0000);
> + //
> + // Video memory + Legacy BIOS region, to allow Linux to boot.
> + //
> + AddReservedMemoryBaseSizeHob (0xA0000, BASE_1MB - 0xA0000, TRUE);
> +
> for (Index = 0; Index < E820EntriesCount; Index++) {
> UINT64 Base;
> UINT64 End;
> @@ -307,6 +313,16 @@ XenPublishRamRegions (
> Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
> End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
>
> + //
> + // Ignore the first 1MB, this is handled before the loop.
> + //
> + if (Base < BASE_1MB) {
> + Base = BASE_1MB;
> + }
> + if (Base >= End) {
> + continue;
> + }
> +
> switch (Entry->Type) {
> case EfiAcpiAddressRangeMemory:
> AddMemoryRangeHob (Base, End);
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 24/31] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
When the device ID of the host bridge is unknown, check if we are
running as a PVH guest as there is no PCI bus in that case.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
v2:
- Use new XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID macro
OvmfPkg/Include/OvmfPlatforms.h | 6 ++++++
OvmfPkg/XenPlatformPei/Platform.c | 7 +++++++
2 files changed, 13 insertions(+)
diff --git a/OvmfPkg/Include/OvmfPlatforms.h b/OvmfPkg/Include/OvmfPlatforms.h
index cc67f40a88..1ce71e18ec 100644
--- a/OvmfPkg/Include/OvmfPlatforms.h
+++ b/OvmfPkg/Include/OvmfPlatforms.h
@@ -43,4 +43,10 @@
//
#define ACPI_TIMER_OFFSET 0x8
+//
+// When running OVMF on a Xen PVH guest there is no PCI,
+// so -1 is return for the Host Bridge Device ID.
+//
+#define XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID 0xFFFF
+
#endif
diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
index 5e6d553ad5..d91cd98bf4 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -278,6 +278,13 @@ MiscInitialization (
AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
break;
default:
+ if (XenPvhDetected ()) {
+ //
+ // There is no PCI bus in this case
+ //
+ PcdSet16S (PcdOvmfHostBridgePciDevId, XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID);
+ return;
+ }
DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
__FUNCTION__, mHostBridgeDevId));
ASSERT (FALSE);
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 24/31] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
When the device ID of the host bridge is unknown, check if we are
running as a PVH guest as there is no PCI bus in that case.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
v2:
- Use new XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID macro
OvmfPkg/Include/OvmfPlatforms.h | 6 ++++++
OvmfPkg/XenPlatformPei/Platform.c | 7 +++++++
2 files changed, 13 insertions(+)
diff --git a/OvmfPkg/Include/OvmfPlatforms.h b/OvmfPkg/Include/OvmfPlatforms.h
index cc67f40a88..1ce71e18ec 100644
--- a/OvmfPkg/Include/OvmfPlatforms.h
+++ b/OvmfPkg/Include/OvmfPlatforms.h
@@ -43,4 +43,10 @@
//
#define ACPI_TIMER_OFFSET 0x8
+//
+// When running OVMF on a Xen PVH guest there is no PCI,
+// so -1 is return for the Host Bridge Device ID.
+//
+#define XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID 0xFFFF
+
#endif
diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
index 5e6d553ad5..d91cd98bf4 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -278,6 +278,13 @@ MiscInitialization (
AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
break;
default:
+ if (XenPvhDetected ()) {
+ //
+ // There is no PCI bus in this case
+ //
+ PcdSet16S (PcdOvmfHostBridgePciDevId, XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID);
+ return;
+ }
DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
__FUNCTION__, mHostBridgeDevId));
ASSERT (FALSE);
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 24/31] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
@ 2019-04-15 13:29 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:29 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> When the device ID of the host bridge is unknown, check if we are
> running as a PVH guest as there is no PCI bus in that case.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> v2:
> - Use new XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID macro
>
> OvmfPkg/Include/OvmfPlatforms.h | 6 ++++++
> OvmfPkg/XenPlatformPei/Platform.c | 7 +++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/OvmfPkg/Include/OvmfPlatforms.h b/OvmfPkg/Include/OvmfPlatforms.h
> index cc67f40a88..1ce71e18ec 100644
> --- a/OvmfPkg/Include/OvmfPlatforms.h
> +++ b/OvmfPkg/Include/OvmfPlatforms.h
> @@ -43,4 +43,10 @@
> //
> #define ACPI_TIMER_OFFSET 0x8
>
> +//
> +// When running OVMF on a Xen PVH guest there is no PCI,
> +// so -1 is return for the Host Bridge Device ID.
> +//
> +#define XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID 0xFFFF
> +
> #endif
We split the i440fx and Q35 host bridge device IDs to separate files,
under "OvmfPkg/Include/IndustryStandard/", in commit cb2e300766ae
("OvmfPkg: split Include/OvmfPlatforms.h", 2015-05-13).
(1) I'd prefer if we could introduce the above macro similarly -- and
include that header only in XenPlatformPei (plus wherever else it is
necessary).
Thanks!
Laszlo
> diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
> index 5e6d553ad5..d91cd98bf4 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -278,6 +278,13 @@ MiscInitialization (
> AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
> break;
> default:
> + if (XenPvhDetected ()) {
> + //
> + // There is no PCI bus in this case
> + //
> + PcdSet16S (PcdOvmfHostBridgePciDevId, XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID);
> + return;
> + }
> DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
> __FUNCTION__, mHostBridgeDevId));
> ASSERT (FALSE);
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 24/31] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
@ 2019-04-15 13:29 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:29 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> When the device ID of the host bridge is unknown, check if we are
> running as a PVH guest as there is no PCI bus in that case.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> v2:
> - Use new XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID macro
>
> OvmfPkg/Include/OvmfPlatforms.h | 6 ++++++
> OvmfPkg/XenPlatformPei/Platform.c | 7 +++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/OvmfPkg/Include/OvmfPlatforms.h b/OvmfPkg/Include/OvmfPlatforms.h
> index cc67f40a88..1ce71e18ec 100644
> --- a/OvmfPkg/Include/OvmfPlatforms.h
> +++ b/OvmfPkg/Include/OvmfPlatforms.h
> @@ -43,4 +43,10 @@
> //
> #define ACPI_TIMER_OFFSET 0x8
>
> +//
> +// When running OVMF on a Xen PVH guest there is no PCI,
> +// so -1 is return for the Host Bridge Device ID.
> +//
> +#define XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID 0xFFFF
> +
> #endif
We split the i440fx and Q35 host bridge device IDs to separate files,
under "OvmfPkg/Include/IndustryStandard/", in commit cb2e300766ae
("OvmfPkg: split Include/OvmfPlatforms.h", 2015-05-13).
(1) I'd prefer if we could introduce the above macro similarly -- and
include that header only in XenPlatformPei (plus wherever else it is
necessary).
Thanks!
Laszlo
> diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
> index 5e6d553ad5..d91cd98bf4 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -278,6 +278,13 @@ MiscInitialization (
> AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
> break;
> default:
> + if (XenPvhDetected ()) {
> + //
> + // There is no PCI bus in this case
> + //
> + PcdSet16S (PcdOvmfHostBridgePciDevId, XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID);
> + return;
> + }
> DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
> __FUNCTION__, mHostBridgeDevId));
> ASSERT (FALSE);
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 24/31] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
@ 2019-04-15 13:33 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:33 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/15/19 15:29, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> When the device ID of the host bridge is unknown, check if we are
>> running as a PVH guest as there is no PCI bus in that case.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>>
>> Notes:
>> v2:
>> - Use new XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID macro
>>
>> OvmfPkg/Include/OvmfPlatforms.h | 6 ++++++
>> OvmfPkg/XenPlatformPei/Platform.c | 7 +++++++
>> 2 files changed, 13 insertions(+)
>>
>> diff --git a/OvmfPkg/Include/OvmfPlatforms.h b/OvmfPkg/Include/OvmfPlatforms.h
>> index cc67f40a88..1ce71e18ec 100644
>> --- a/OvmfPkg/Include/OvmfPlatforms.h
>> +++ b/OvmfPkg/Include/OvmfPlatforms.h
>> @@ -43,4 +43,10 @@
>> //
>> #define ACPI_TIMER_OFFSET 0x8
>>
>> +//
>> +// When running OVMF on a Xen PVH guest there is no PCI,
>> +// so -1 is return for the Host Bridge Device ID.
>> +//
>> +#define XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID 0xFFFF
>> +
>> #endif
>
> We split the i440fx and Q35 host bridge device IDs to separate files,
> under "OvmfPkg/Include/IndustryStandard/", in commit cb2e300766ae
> ("OvmfPkg: split Include/OvmfPlatforms.h", 2015-05-13).
>
> (1) I'd prefer if we could introduce the above macro similarly -- and
> include that header only in XenPlatformPei (plus wherever else it is
> necessary).
sorry, for a second I missed:
#include <IndustryStandard/Q35MchIch9.h>
#include <IndustryStandard/I440FxPiix4.h>
in "OvmfPlatforms.h". So it's fine to #include the new Xen-specific
header in "OvmfPlatforms.h", centrally.
Thanks
Laszlo
>
> Thanks!
> Laszlo
>
>
>> diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
>> index 5e6d553ad5..d91cd98bf4 100644
>> --- a/OvmfPkg/XenPlatformPei/Platform.c
>> +++ b/OvmfPkg/XenPlatformPei/Platform.c
>> @@ -278,6 +278,13 @@ MiscInitialization (
>> AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
>> break;
>> default:
>> + if (XenPvhDetected ()) {
>> + //
>> + // There is no PCI bus in this case
>> + //
>> + PcdSet16S (PcdOvmfHostBridgePciDevId, XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID);
>> + return;
>> + }
>> DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
>> __FUNCTION__, mHostBridgeDevId));
>> ASSERT (FALSE);
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 24/31] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
@ 2019-04-15 13:33 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:33 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/15/19 15:29, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> When the device ID of the host bridge is unknown, check if we are
>> running as a PVH guest as there is no PCI bus in that case.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>>
>> Notes:
>> v2:
>> - Use new XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID macro
>>
>> OvmfPkg/Include/OvmfPlatforms.h | 6 ++++++
>> OvmfPkg/XenPlatformPei/Platform.c | 7 +++++++
>> 2 files changed, 13 insertions(+)
>>
>> diff --git a/OvmfPkg/Include/OvmfPlatforms.h b/OvmfPkg/Include/OvmfPlatforms.h
>> index cc67f40a88..1ce71e18ec 100644
>> --- a/OvmfPkg/Include/OvmfPlatforms.h
>> +++ b/OvmfPkg/Include/OvmfPlatforms.h
>> @@ -43,4 +43,10 @@
>> //
>> #define ACPI_TIMER_OFFSET 0x8
>>
>> +//
>> +// When running OVMF on a Xen PVH guest there is no PCI,
>> +// so -1 is return for the Host Bridge Device ID.
>> +//
>> +#define XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID 0xFFFF
>> +
>> #endif
>
> We split the i440fx and Q35 host bridge device IDs to separate files,
> under "OvmfPkg/Include/IndustryStandard/", in commit cb2e300766ae
> ("OvmfPkg: split Include/OvmfPlatforms.h", 2015-05-13).
>
> (1) I'd prefer if we could introduce the above macro similarly -- and
> include that header only in XenPlatformPei (plus wherever else it is
> necessary).
sorry, for a second I missed:
#include <IndustryStandard/Q35MchIch9.h>
#include <IndustryStandard/I440FxPiix4.h>
in "OvmfPlatforms.h". So it's fine to #include the new Xen-specific
header in "OvmfPlatforms.h", centrally.
Thanks
Laszlo
>
> Thanks!
> Laszlo
>
>
>> diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
>> index 5e6d553ad5..d91cd98bf4 100644
>> --- a/OvmfPkg/XenPlatformPei/Platform.c
>> +++ b/OvmfPkg/XenPlatformPei/Platform.c
>> @@ -278,6 +278,13 @@ MiscInitialization (
>> AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
>> break;
>> default:
>> + if (XenPvhDetected ()) {
>> + //
>> + // There is no PCI bus in this case
>> + //
>> + PcdSet16S (PcdOvmfHostBridgePciDevId, XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID);
>> + return;
>> + }
>> DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
>> __FUNCTION__, mHostBridgeDevId));
>> ASSERT (FALSE);
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [PATCH v2 24/31] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
@ 2019-04-15 13:37 ` Andrew Cooper
0 siblings, 0 replies; 168+ messages in thread
From: Andrew Cooper @ 2019-04-15 13:37 UTC (permalink / raw)
To: Anthony PERARD, devel
Cc: Jordan Justen, Julien Grall, Laszlo Ersek, xen-devel, Ard Biesheuvel
On 09/04/2019 12:08, Anthony PERARD wrote:
> diff --git a/OvmfPkg/Include/OvmfPlatforms.h b/OvmfPkg/Include/OvmfPlatforms.h
> index cc67f40a88..1ce71e18ec 100644
> --- a/OvmfPkg/Include/OvmfPlatforms.h
> +++ b/OvmfPkg/Include/OvmfPlatforms.h
> @@ -43,4 +43,10 @@
> //
> #define ACPI_TIMER_OFFSET 0x8
>
> +//
> +// When running OVMF on a Xen PVH guest there is no PCI,
> +// so -1 is return for the Host Bridge Device ID.
> +//
> +#define XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID 0xFFFF
This isn't anything Xen specific - it is a property of how PCI config
cycles work.
> +
> #endif
> diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
> index 5e6d553ad5..d91cd98bf4 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -278,6 +278,13 @@ MiscInitialization (
> AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
> break;
> default:
> + if (XenPvhDetected ()) {
> + //
> + // There is no PCI bus in this case
> + //
> + PcdSet16S (PcdOvmfHostBridgePciDevId, XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID);
This is not correct.
There may be no PCI bus, and OVMF needs to cope with this case, but
there may also be one (especially once we get around to making PCI
Passthrough work with PVH guests). That case needs to work too.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [PATCH v2 24/31] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
@ 2019-04-15 13:37 ` Andrew Cooper
0 siblings, 0 replies; 168+ messages in thread
From: Andrew Cooper @ 2019-04-15 13:37 UTC (permalink / raw)
To: Anthony PERARD, devel
Cc: Jordan Justen, Julien Grall, Laszlo Ersek, xen-devel, Ard Biesheuvel
On 09/04/2019 12:08, Anthony PERARD wrote:
> diff --git a/OvmfPkg/Include/OvmfPlatforms.h b/OvmfPkg/Include/OvmfPlatforms.h
> index cc67f40a88..1ce71e18ec 100644
> --- a/OvmfPkg/Include/OvmfPlatforms.h
> +++ b/OvmfPkg/Include/OvmfPlatforms.h
> @@ -43,4 +43,10 @@
> //
> #define ACPI_TIMER_OFFSET 0x8
>
> +//
> +// When running OVMF on a Xen PVH guest there is no PCI,
> +// so -1 is return for the Host Bridge Device ID.
> +//
> +#define XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID 0xFFFF
This isn't anything Xen specific - it is a property of how PCI config
cycles work.
> +
> #endif
> diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
> index 5e6d553ad5..d91cd98bf4 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -278,6 +278,13 @@ MiscInitialization (
> AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
> break;
> default:
> + if (XenPvhDetected ()) {
> + //
> + // There is no PCI bus in this case
> + //
> + PcdSet16S (PcdOvmfHostBridgePciDevId, XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID);
This is not correct.
There may be no PCI bus, and OVMF needs to cope with this case, but
there may also be one (especially once we get around to making PCI
Passthrough work with PVH guests). That case needs to work too.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
When running on PVH without PCI bus, the XenPlatformPei will set
PcdOvmfHostBridgePciDevId to XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 12303fb0f1..1a6d47732e 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1213,6 +1213,11 @@ PciAcpiInitialization (
PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
break;
+ case XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID:
+ //
+ // There are no PCI bus in this case.
+ //
+ return;
default:
DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
__FUNCTION__, mHostBridgeDevId));
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
When running on PVH without PCI bus, the XenPlatformPei will set
PcdOvmfHostBridgePciDevId to XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 12303fb0f1..1a6d47732e 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1213,6 +1213,11 @@ PciAcpiInitialization (
PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
break;
+ case XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID:
+ //
+ // There are no PCI bus in this case.
+ //
+ return;
default:
DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
__FUNCTION__, mHostBridgeDevId));
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
@ 2019-04-15 13:33 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:33 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> When running on PVH without PCI bus, the XenPlatformPei will set
> PcdOvmfHostBridgePciDevId to XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> index 12303fb0f1..1a6d47732e 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -1213,6 +1213,11 @@ PciAcpiInitialization (
> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
> break;
> + case XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID:
> + //
> + // There are no PCI bus in this case.
(1) s/are/is/, please
with that:
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
> + //
> + return;
> default:
> DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
> __FUNCTION__, mHostBridgeDevId));
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
@ 2019-04-15 13:33 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:33 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> When running on PVH without PCI bus, the XenPlatformPei will set
> PcdOvmfHostBridgePciDevId to XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> index 12303fb0f1..1a6d47732e 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -1213,6 +1213,11 @@ PciAcpiInitialization (
> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
> break;
> + case XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID:
> + //
> + // There are no PCI bus in this case.
(1) s/are/is/, please
with that:
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
> + //
> + return;
> default:
> DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
> __FUNCTION__, mHostBridgeDevId));
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [edk2-devel] [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
@ 2019-04-15 13:49 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:49 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/15/19 15:33, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> When running on PVH without PCI bus, the XenPlatformPei will set
>> PcdOvmfHostBridgePciDevId to XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> index 12303fb0f1..1a6d47732e 100644
>> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> @@ -1213,6 +1213,11 @@ PciAcpiInitialization (
>> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
>> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
>> break;
>> + case XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID:
>> + //
>> + // There are no PCI bus in this case.
>
> (1) s/are/is/, please
>
> with that:
>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
(Sigh. I have to apologize for my comments that might look "rushed". The
fact is that, despite it being only Monday, I'm already exhausted. It's
Monday *afternoon*, after all.
A "normal" maintainer in my position would probably not look at patches
from this series for days on end, possibly for multiple weeks even. I on
the other hand intend to make a bit of progress every day I possibly
can. The result is that my comments are not always 100% polished when I
send them, due to fatigue. Sorry about that.)
So, my thought on this is that XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID is too
generic to accept here. It will alias at least *some* failures to read
the underlying PCI config space register.
In XenPlatformPei (v2 24/31), that's not an issue, for two reasons:
- there is a specific, additional, XenPvhDetected() check,
- even if there was an issue with the logic, it'd only affect
XenPlatformPei; i.e. the OvmfXen platform.
(2) Can you
- introduce XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID with a value different
from 0xFFFF perhaps?
- or keep it as 0xFFFF, but rely on PcdPciDisableBusEnumeration, as a
further restriction?
(I understand that exposing XenPvhDetected() to PlatformBootManagerLib
would require more PVH enlightenment in "common" code, and, indeed, I
don't desire that -- that's why I'm suggesting
PcdPciDisableBusEnumeration)
Thanks,
Laszlo
>> + //
>> + return;
>> default:
>> DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
>> __FUNCTION__, mHostBridgeDevId));
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
@ 2019-04-15 13:49 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:49 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/15/19 15:33, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> When running on PVH without PCI bus, the XenPlatformPei will set
>> PcdOvmfHostBridgePciDevId to XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> index 12303fb0f1..1a6d47732e 100644
>> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> @@ -1213,6 +1213,11 @@ PciAcpiInitialization (
>> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
>> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
>> break;
>> + case XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID:
>> + //
>> + // There are no PCI bus in this case.
>
> (1) s/are/is/, please
>
> with that:
>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
(Sigh. I have to apologize for my comments that might look "rushed". The
fact is that, despite it being only Monday, I'm already exhausted. It's
Monday *afternoon*, after all.
A "normal" maintainer in my position would probably not look at patches
from this series for days on end, possibly for multiple weeks even. I on
the other hand intend to make a bit of progress every day I possibly
can. The result is that my comments are not always 100% polished when I
send them, due to fatigue. Sorry about that.)
So, my thought on this is that XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID is too
generic to accept here. It will alias at least *some* failures to read
the underlying PCI config space register.
In XenPlatformPei (v2 24/31), that's not an issue, for two reasons:
- there is a specific, additional, XenPvhDetected() check,
- even if there was an issue with the logic, it'd only affect
XenPlatformPei; i.e. the OvmfXen platform.
(2) Can you
- introduce XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID with a value different
from 0xFFFF perhaps?
- or keep it as 0xFFFF, but rely on PcdPciDisableBusEnumeration, as a
further restriction?
(I understand that exposing XenPvhDetected() to PlatformBootManagerLib
would require more PVH enlightenment in "common" code, and, indeed, I
don't desire that -- that's why I'm suggesting
PcdPciDisableBusEnumeration)
Thanks,
Laszlo
>> + //
>> + return;
>> default:
>> DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
>> __FUNCTION__, mHostBridgeDevId));
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: [edk2-devel] [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
@ 2019-04-15 14:40 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-15 14:40 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Jordan Justen, devel, xen-devel, Julien Grall, Ard Biesheuvel
On Mon, Apr 15, 2019 at 03:49:25PM +0200, Laszlo Ersek wrote:
> On 04/15/19 15:33, Laszlo Ersek wrote:
> > On 04/09/19 13:08, Anthony PERARD wrote:
> >> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> >> index 12303fb0f1..1a6d47732e 100644
> >> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> >> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> >> @@ -1213,6 +1213,11 @@ PciAcpiInitialization (
> >> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
> >> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
> >> break;
> >> + case XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID:
> (Sigh. I have to apologize for my comments that might look "rushed". The
> fact is that, despite it being only Monday, I'm already exhausted. It's
> Monday *afternoon*, after all.
>
> A "normal" maintainer in my position would probably not look at patches
> from this series for days on end, possibly for multiple weeks even. I on
> the other hand intend to make a bit of progress every day I possibly
> can. The result is that my comments are not always 100% polished when I
> send them, due to fatigue. Sorry about that.)
No worries, take your time. And thanks for you details reviews.
> So, my thought on this is that XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID is too
> generic to accept here. It will alias at least *some* failures to read
> the underlying PCI config space register.
>
> In XenPlatformPei (v2 24/31), that's not an issue, for two reasons:
>
> - there is a specific, additional, XenPvhDetected() check,
> - even if there was an issue with the logic, it'd only affect
> XenPlatformPei; i.e. the OvmfXen platform.
>
> (2) Can you
>
> - introduce XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID with a value different
> from 0xFFFF perhaps?
>
> - or keep it as 0xFFFF, but rely on PcdPciDisableBusEnumeration, as a
> further restriction?
>
> (I understand that exposing XenPvhDetected() to PlatformBootManagerLib
> would require more PVH enlightenment in "common" code, and, indeed, I
> don't desire that -- that's why I'm suggesting
> PcdPciDisableBusEnumeration)
So, PlatformBootManagerLib already has a XenDetected() function, so
I could use that function.
I think we could stop using XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID (because I
don't know what value I could use) and not set
`PcdOvmfHostBridgePciDevId' at all, it would default to 0x0.
Then, in PlatformBootManagerLib, simply ignore the error when
mHostBridgeDevId (or PcdOvmfHostBridgePciDevId) isn't recognise and when
XenDetected() is true.
Would that be fine?
The patch would look something like this:
@@ -1222,6 +1222,12 @@ PciAcpiInitialization (
PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
break;
default:
+ if (XenDetected ()) {
+ //
+ // There is no PCI bus in this case.
+ //
+ return;
+ }
DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
@ 2019-04-15 14:40 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-15 14:40 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Jordan Justen, devel, xen-devel, Julien Grall, Ard Biesheuvel
On Mon, Apr 15, 2019 at 03:49:25PM +0200, Laszlo Ersek wrote:
> On 04/15/19 15:33, Laszlo Ersek wrote:
> > On 04/09/19 13:08, Anthony PERARD wrote:
> >> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> >> index 12303fb0f1..1a6d47732e 100644
> >> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> >> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> >> @@ -1213,6 +1213,11 @@ PciAcpiInitialization (
> >> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
> >> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
> >> break;
> >> + case XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID:
> (Sigh. I have to apologize for my comments that might look "rushed". The
> fact is that, despite it being only Monday, I'm already exhausted. It's
> Monday *afternoon*, after all.
>
> A "normal" maintainer in my position would probably not look at patches
> from this series for days on end, possibly for multiple weeks even. I on
> the other hand intend to make a bit of progress every day I possibly
> can. The result is that my comments are not always 100% polished when I
> send them, due to fatigue. Sorry about that.)
No worries, take your time. And thanks for you details reviews.
> So, my thought on this is that XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID is too
> generic to accept here. It will alias at least *some* failures to read
> the underlying PCI config space register.
>
> In XenPlatformPei (v2 24/31), that's not an issue, for two reasons:
>
> - there is a specific, additional, XenPvhDetected() check,
> - even if there was an issue with the logic, it'd only affect
> XenPlatformPei; i.e. the OvmfXen platform.
>
> (2) Can you
>
> - introduce XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID with a value different
> from 0xFFFF perhaps?
>
> - or keep it as 0xFFFF, but rely on PcdPciDisableBusEnumeration, as a
> further restriction?
>
> (I understand that exposing XenPvhDetected() to PlatformBootManagerLib
> would require more PVH enlightenment in "common" code, and, indeed, I
> don't desire that -- that's why I'm suggesting
> PcdPciDisableBusEnumeration)
So, PlatformBootManagerLib already has a XenDetected() function, so
I could use that function.
I think we could stop using XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID (because I
don't know what value I could use) and not set
`PcdOvmfHostBridgePciDevId' at all, it would default to 0x0.
Then, in PlatformBootManagerLib, simply ignore the error when
mHostBridgeDevId (or PcdOvmfHostBridgePciDevId) isn't recognise and when
XenDetected() is true.
Would that be fine?
The patch would look something like this:
@@ -1222,6 +1222,12 @@ PciAcpiInitialization (
PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
break;
default:
+ if (XenDetected ()) {
+ //
+ // There is no PCI bus in this case.
+ //
+ return;
+ }
DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
@ 2019-04-15 17:57 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 17:57 UTC (permalink / raw)
To: Anthony PERARD
Cc: Jordan Justen, devel, xen-devel, Julien Grall, Ard Biesheuvel
On 04/15/19 16:40, Anthony PERARD wrote:
> On Mon, Apr 15, 2019 at 03:49:25PM +0200, Laszlo Ersek wrote:
>> On 04/15/19 15:33, Laszlo Ersek wrote:
>>> On 04/09/19 13:08, Anthony PERARD wrote:
>>>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>>>> index 12303fb0f1..1a6d47732e 100644
>>>> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>>>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>>>> @@ -1213,6 +1213,11 @@ PciAcpiInitialization (
>>>> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
>>>> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
>>>> break;
>>>> + case XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID:
>> (Sigh. I have to apologize for my comments that might look "rushed". The
>> fact is that, despite it being only Monday, I'm already exhausted. It's
>> Monday *afternoon*, after all.
>>
>> A "normal" maintainer in my position would probably not look at patches
>> from this series for days on end, possibly for multiple weeks even. I on
>> the other hand intend to make a bit of progress every day I possibly
>> can. The result is that my comments are not always 100% polished when I
>> send them, due to fatigue. Sorry about that.)
>
> No worries, take your time. And thanks for you details reviews.
>
>> So, my thought on this is that XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID is too
>> generic to accept here. It will alias at least *some* failures to read
>> the underlying PCI config space register.
>>
>> In XenPlatformPei (v2 24/31), that's not an issue, for two reasons:
>>
>> - there is a specific, additional, XenPvhDetected() check,
>> - even if there was an issue with the logic, it'd only affect
>> XenPlatformPei; i.e. the OvmfXen platform.
>>
>> (2) Can you
>>
>> - introduce XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID with a value different
>> from 0xFFFF perhaps?
>>
>> - or keep it as 0xFFFF, but rely on PcdPciDisableBusEnumeration, as a
>> further restriction?
>>
>> (I understand that exposing XenPvhDetected() to PlatformBootManagerLib
>> would require more PVH enlightenment in "common" code, and, indeed, I
>> don't desire that -- that's why I'm suggesting
>> PcdPciDisableBusEnumeration)
>
> So, PlatformBootManagerLib already has a XenDetected() function, so
> I could use that function.
Right, if we can detect Xen (both HVM+PVH, or just PVH, whichever is
appropriate) here, that sounds good. For that, I suggested elsewhere to
rebase PlatformBootManagerLib first on top of XenPlatformLib, to
eliminate the duplicate XenDetected() function definition.
>
> I think we could stop using XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID (because I
> don't know what value I could use) and not set
> `PcdOvmfHostBridgePciDevId' at all, it would default to 0x0.
That should work.
> Then, in PlatformBootManagerLib, simply ignore the error when
> mHostBridgeDevId (or PcdOvmfHostBridgePciDevId) isn't recognise and when
> XenDetected() is true.
>
> Would that be fine?
Yes, sounds good.
>
> The patch would look something like this:
>
> @@ -1222,6 +1222,12 @@ PciAcpiInitialization (
> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
> break;
> default:
> + if (XenDetected ()) {
> + //
> + // There is no PCI bus in this case.
> + //
> + return;
> + }
> DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
>
>
Looks OK!
Thanks!
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
@ 2019-04-15 17:57 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 17:57 UTC (permalink / raw)
To: Anthony PERARD
Cc: Jordan Justen, devel, xen-devel, Julien Grall, Ard Biesheuvel
On 04/15/19 16:40, Anthony PERARD wrote:
> On Mon, Apr 15, 2019 at 03:49:25PM +0200, Laszlo Ersek wrote:
>> On 04/15/19 15:33, Laszlo Ersek wrote:
>>> On 04/09/19 13:08, Anthony PERARD wrote:
>>>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>>>> index 12303fb0f1..1a6d47732e 100644
>>>> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>>>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>>>> @@ -1213,6 +1213,11 @@ PciAcpiInitialization (
>>>> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
>>>> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
>>>> break;
>>>> + case XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID:
>> (Sigh. I have to apologize for my comments that might look "rushed". The
>> fact is that, despite it being only Monday, I'm already exhausted. It's
>> Monday *afternoon*, after all.
>>
>> A "normal" maintainer in my position would probably not look at patches
>> from this series for days on end, possibly for multiple weeks even. I on
>> the other hand intend to make a bit of progress every day I possibly
>> can. The result is that my comments are not always 100% polished when I
>> send them, due to fatigue. Sorry about that.)
>
> No worries, take your time. And thanks for you details reviews.
>
>> So, my thought on this is that XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID is too
>> generic to accept here. It will alias at least *some* failures to read
>> the underlying PCI config space register.
>>
>> In XenPlatformPei (v2 24/31), that's not an issue, for two reasons:
>>
>> - there is a specific, additional, XenPvhDetected() check,
>> - even if there was an issue with the logic, it'd only affect
>> XenPlatformPei; i.e. the OvmfXen platform.
>>
>> (2) Can you
>>
>> - introduce XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID with a value different
>> from 0xFFFF perhaps?
>>
>> - or keep it as 0xFFFF, but rely on PcdPciDisableBusEnumeration, as a
>> further restriction?
>>
>> (I understand that exposing XenPvhDetected() to PlatformBootManagerLib
>> would require more PVH enlightenment in "common" code, and, indeed, I
>> don't desire that -- that's why I'm suggesting
>> PcdPciDisableBusEnumeration)
>
> So, PlatformBootManagerLib already has a XenDetected() function, so
> I could use that function.
Right, if we can detect Xen (both HVM+PVH, or just PVH, whichever is
appropriate) here, that sounds good. For that, I suggested elsewhere to
rebase PlatformBootManagerLib first on top of XenPlatformLib, to
eliminate the duplicate XenDetected() function definition.
>
> I think we could stop using XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID (because I
> don't know what value I could use) and not set
> `PcdOvmfHostBridgePciDevId' at all, it would default to 0x0.
That should work.
> Then, in PlatformBootManagerLib, simply ignore the error when
> mHostBridgeDevId (or PcdOvmfHostBridgePciDevId) isn't recognise and when
> XenDetected() is true.
>
> Would that be fine?
Yes, sounds good.
>
> The patch would look something like this:
>
> @@ -1222,6 +1222,12 @@ PciAcpiInitialization (
> PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
> break;
> default:
> + if (XenDetected ()) {
> + //
> + // There is no PCI bus in this case.
> + //
> + return;
> + }
> DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
>
>
Looks OK!
Thanks!
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 26/31] OvmfPkg/XenOvmf: Override PcdFSBClock to Xen vLAPIC timer frequency
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
That value is used by SecPeiDxeTimerLibCpu, the TimerLib implementation.
It will also be used by XenTimerDxe.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
new patch in v2.
OvmfPkg/XenOvmf.dsc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 9529b4834f..54601c697f 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -452,6 +452,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|100000000
+
################################################################################
#
# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 26/31] OvmfPkg/XenOvmf: Override PcdFSBClock to Xen vLAPIC timer frequency
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
That value is used by SecPeiDxeTimerLibCpu, the TimerLib implementation.
It will also be used by XenTimerDxe.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
new patch in v2.
OvmfPkg/XenOvmf.dsc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 9529b4834f..54601c697f 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -452,6 +452,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|100000000
+
################################################################################
#
# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 26/31] OvmfPkg/XenOvmf: Override PcdFSBClock to Xen vLAPIC timer frequency
@ 2019-04-15 13:52 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:52 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> That value is used by SecPeiDxeTimerLibCpu, the TimerLib implementation.
> It will also be used by XenTimerDxe.
(1) please expand "that value".
with that,
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> new patch in v2.
>
> OvmfPkg/XenOvmf.dsc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 9529b4834f..54601c697f 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -452,6 +452,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|100000000
> +
> ################################################################################
> #
> # Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 26/31] OvmfPkg/XenOvmf: Override PcdFSBClock to Xen vLAPIC timer frequency
@ 2019-04-15 13:52 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 13:52 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> That value is used by SecPeiDxeTimerLibCpu, the TimerLib implementation.
> It will also be used by XenTimerDxe.
(1) please expand "that value".
with that,
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> new patch in v2.
>
> OvmfPkg/XenOvmf.dsc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 9529b4834f..54601c697f 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -452,6 +452,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|100000000
> +
> ################################################################################
> #
> # Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 27/31] OvmfPkg/XenOvmf: Introduce XenTimerDxe
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
"PcAtChipsetPkg/8254TimerDxe" is replaced with a Xen-specific
EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
8259InterruptControllerDxe as it is not used anymore.
This Timer uses the local APIC timer as time source as it can work on
both a Xen PVH guest and an HVM one.
Based on the "PcAtChipsetPkg/8254TimerDxe" implementation.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
v2:
- Use InitializeApicTimer instead of WriteLocalApicReg
- rework comments (remove many that don't apply)
- remove unused includes, and libs
- have a macro to the timervector.
- cleanup, copyright
- rework calculation of TimerCount, value to be use by the APIC timer
- check for overflow of TimerPeriod, with the apic timer, the period can
be up to about 42s on Xen (or even higher by changing the DivideValue).
OvmfPkg/XenOvmf.dsc | 3 +-
OvmfPkg/XenOvmf.fdf | 3 +-
PcAtChipsetPkg/8254TimerDxe/8254Timer.inf => OvmfPkg/XenTimerDxe/XenTimerDxe.inf | 27 +++---
PcAtChipsetPkg/8254TimerDxe/Timer.h => OvmfPkg/XenTimerDxe/XenTimerDxe.h | 32 +++----
PcAtChipsetPkg/8254TimerDxe/Timer.c => OvmfPkg/XenTimerDxe/XenTimerDxe.c | 100 ++++++--------------
5 files changed, 55 insertions(+), 110 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 54601c697f..35af05715b 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -560,10 +560,9 @@ [Components]
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
- PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+ OvmfPkg/XenTimerDxe/XenTimerDxe.inf
UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
UefiCpuPkg/CpuDxe/CpuDxe.inf
- PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index f9e58befd6..d614bdce1d 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -284,10 +284,9 @@ [FV.DXEFV]
INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
INF MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+INF OvmfPkg/XenTimerDxe/XenTimerDxe.inf
INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
INF UefiCpuPkg/CpuDxe/CpuDxe.inf
-INF PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
INF OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
INF OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
diff --git a/PcAtChipsetPkg/8254TimerDxe/8254Timer.inf b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
similarity index 64%
copy from PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
copy to OvmfPkg/XenTimerDxe/XenTimerDxe.inf
index 46cf01de39..5ad80b9368 100644
--- a/PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
@@ -1,7 +1,9 @@
## @file
-# 8254 timer driver that provides Timer Arch protocol.
+# Local APIC timer driver that provides Timer Arch protocol.
+#
+# Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
#
-# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
# which accompanies this distribution. The full text of the license may be found at
@@ -14,9 +16,8 @@
[Defines]
INF_VERSION = 0x00010005
- BASE_NAME = Timer
- MODULE_UNI_FILE = Timer.uni
- FILE_GUID = f2765dec-6b41-11d5-8e71-00902707b35e
+ BASE_NAME = XenTimerDxe
+ FILE_GUID = 52fe8196-f9de-4d07-b22f-51f77a0e7c41
MODULE_TYPE = DXE_DRIVER
VERSION_STRING = 1.0
@@ -25,24 +26,24 @@ [Defines]
[Packages]
MdePkg/MdePkg.dec
IntelFrameworkPkg/IntelFrameworkPkg.dec
+ UefiCpuPkg/UefiCpuPkg.dec
+ OvmfPkg/OvmfPkg.dec
[LibraryClasses]
UefiBootServicesTableLib
BaseLib
DebugLib
UefiDriverEntryPoint
- IoLib
+ LocalApicLib
[Sources]
- Timer.h
- Timer.c
+ XenTimerDxe.h
+ XenTimerDxe.c
[Protocols]
gEfiCpuArchProtocolGuid ## CONSUMES
- gEfiLegacy8259ProtocolGuid ## CONSUMES
gEfiTimerArchProtocolGuid ## PRODUCES
-
+[Pcd]
+ gEfiMdePkgTokenSpaceGuid.PcdFSBClock ## CONSUMES
[Depex]
- gEfiCpuArchProtocolGuid AND gEfiLegacy8259ProtocolGuid
-[UserExtensions.TianoCore."ExtraFiles"]
- TimerExtra.uni
+ gEfiCpuArchProtocolGuid
diff --git a/PcAtChipsetPkg/8254TimerDxe/Timer.h b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
similarity index 89%
copy from PcAtChipsetPkg/8254TimerDxe/Timer.h
copy to OvmfPkg/XenTimerDxe/XenTimerDxe.h
index 9d70e3aa19..747259c162 100644
--- a/PcAtChipsetPkg/8254TimerDxe/Timer.h
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
@@ -1,7 +1,9 @@
/** @file
Private data structures
-Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -17,34 +19,24 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
#include <PiDxe.h>
#include <Protocol/Cpu.h>
-#include <Protocol/Legacy8259.h>
#include <Protocol/Timer.h>
+#include <Register/LocalApic.h>
+
#include <Library/UefiBootServicesTableLib.h>
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
-#include <Library/IoLib.h>
+#include <Library/LocalApicLib.h>
+#include <Library/PcdLib.h>
-//
-// The PCAT 8253/8254 has an input clock at 1.193182 MHz and Timer 0 is
-// initialized as a 16 bit free running counter that generates an interrupt(IRQ0)
-// each time the counter rolls over.
-//
-// 65536 counts
-// ---------------- * 1,000,000 uS/S = 54925.4 uS = 549254 * 100 ns
-// 1,193,182 Hz
-//
-
-//
-// The maximum tick duration for 8254 timer
-//
-#define MAX_TIMER_TICK_DURATION 549254
-//
// The default timer tick duration is set to 10 ms = 100000 100 ns units
//
#define DEFAULT_TIMER_TICK_DURATION 100000
-#define TIMER_CONTROL_PORT 0x43
-#define TIMER0_COUNT_PORT 0x40
+
+//
+// The Timer Vector use for interrupt
+//
+#define LOCAL_APIC_TIMER_VECTOR 32
//
// Function Prototypes
diff --git a/PcAtChipsetPkg/8254TimerDxe/Timer.c b/OvmfPkg/XenTimerDxe/XenTimerDxe.c
similarity index 77%
copy from PcAtChipsetPkg/8254TimerDxe/Timer.c
copy to OvmfPkg/XenTimerDxe/XenTimerDxe.c
index 60799aadd3..fb39ce0cd3 100644
--- a/PcAtChipsetPkg/8254TimerDxe/Timer.c
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.c
@@ -1,7 +1,9 @@
/** @file
Timer Architectural Protocol as defined in the DXE CIS
-Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -12,7 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
**/
-#include "Timer.h"
+#include "XenTimerDxe.h"
//
// The handle onto which the Timer Architectural Protocol will be installed
@@ -34,11 +36,6 @@ EFI_TIMER_ARCH_PROTOCOL mTimer = {
//
EFI_CPU_ARCH_PROTOCOL *mCpu;
-//
-// Pointer to the Legacy 8259 Protocol instance
-//
-EFI_LEGACY_8259_PROTOCOL *mLegacy8259;
-
//
// The notification function to call on every timer interrupt.
// A bug in the compiler prevents us from initializing this here.
@@ -54,22 +51,7 @@ volatile UINT64 mTimerPeriod = 0;
// Worker Functions
//
/**
- Sets the counter value for Timer #0 in a legacy 8254 timer.
-
- @param Count The 16-bit counter value to program into Timer #0 of the legacy 8254 timer.
-**/
-VOID
-SetPitCount (
- IN UINT16 Count
- )
-{
- IoWrite8 (TIMER_CONTROL_PORT, 0x36);
- IoWrite8 (TIMER0_COUNT_PORT, (UINT8)(Count & 0xff));
- IoWrite8 (TIMER0_COUNT_PORT, (UINT8)((Count >> 8) & 0xff));
-}
-
-/**
- 8254 Timer #0 Interrupt Handler.
+ Interrupt Handler.
@param InterruptType The type of interrupt that occurred
@param SystemContext A pointer to the system context when the interrupt occurred
@@ -85,7 +67,7 @@ TimerInterruptHandler (
OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
- mLegacy8259->EndOfInterrupt (mLegacy8259, Efi8259Irq0);
+ SendApicEoi();
if (mTimerNotifyFunction != NULL) {
//
@@ -187,49 +169,41 @@ TimerDriverSetTimerPeriod (
)
{
UINT64 TimerCount;
+ UINT32 TimerFrequency;
+ UINTN DivideValue = 1;
- //
- // The basic clock is 1.19318 MHz or 0.119318 ticks per 100 ns.
- // TimerPeriod * 0.119318 = 8254 timer divisor. Using integer arithmetic
- // TimerCount = (TimerPeriod * 119318)/1000000.
- //
- // Round up to next highest integer. This guarantees that the timer is
- // equal to or slightly longer than the requested time.
- // TimerCount = ((TimerPeriod * 119318) + 500000)/1000000
- //
- // Note that a TimerCount of 0 is equivalent to a count of 65,536
- //
- // Since TimerCount is limited to 16 bits for IA32, TimerPeriod is limited
- // to 20 bits.
- //
if (TimerPeriod == 0) {
//
// Disable timer interrupt for a TimerPeriod of 0
//
- mLegacy8259->DisableIrq (mLegacy8259, Efi8259Irq0);
+ DisableApicTimerInterrupt();
} else {
+ TimerFrequency = PcdGet32(PcdFSBClock) / DivideValue;
//
- // Convert TimerPeriod into 8254 counts
+ // Convert TimerPeriod into local APIC counts
//
- TimerCount = DivU64x32 (MultU64x32 (119318, (UINT32) TimerPeriod) + 500000, 1000000);
+ // TimerPeriod is in 100ns
+ // TimerPeriod/10000000 will be in seconds.
+ TimerCount = DivU64x32 (MultU64x32 (TimerPeriod, TimerFrequency),
+ 10000000);
- //
// Check for overflow
- //
- if (TimerCount >= 65536) {
- TimerCount = 0;
- TimerPeriod = MAX_TIMER_TICK_DURATION;
+ if (TimerCount > MAX_UINT32) {
+ TimerCount = MAX_UINT32;
+ /* TimerPeriod = (MAX_UINT32 / TimerFrequency) * 10000000; */
+ TimerPeriod = 429496730;
}
+
//
- // Program the 8254 timer with the new count value
+ // Program the timer with the new count value
//
- SetPitCount ((UINT16) TimerCount);
+ InitializeApicTimer(DivideValue, TimerCount, TRUE, LOCAL_APIC_TIMER_VECTOR);
//
// Enable timer interrupt
//
- mLegacy8259->EnableIrq (mLegacy8259, Efi8259Irq0, FALSE);
+ EnableApicTimerInterrupt();
}
//
// Save the new timer period
@@ -294,16 +268,9 @@ TimerDriverGenerateSoftInterrupt (
IN EFI_TIMER_ARCH_PROTOCOL *This
)
{
- EFI_STATUS Status;
- UINT16 IRQMask;
EFI_TPL OriginalTPL;
- //
- // If the timer interrupt is enabled, then the registered handler will be invoked.
- //
- Status = mLegacy8259->GetMask (mLegacy8259, NULL, NULL, &IRQMask, NULL);
- ASSERT_EFI_ERROR (Status);
- if ((IRQMask & 0x1) == 0) {
+ if (GetApicTimerInterruptState()) {
//
// Invoke the registered handler
//
@@ -343,7 +310,6 @@ TimerDriverInitialize (
)
{
EFI_STATUS Status;
- UINT32 TimerVector;
//
// Initialize the pointer to our notify function.
@@ -361,12 +327,6 @@ TimerDriverInitialize (
Status = gBS->LocateProtocol (&gEfiCpuArchProtocolGuid, NULL, (VOID **) &mCpu);
ASSERT_EFI_ERROR (Status);
- //
- // Find the Legacy8259 protocol.
- //
- Status = gBS->LocateProtocol (&gEfiLegacy8259ProtocolGuid, NULL, (VOID **) &mLegacy8259);
- ASSERT_EFI_ERROR (Status);
-
//
// Force the timer to be disabled
//
@@ -374,16 +334,10 @@ TimerDriverInitialize (
ASSERT_EFI_ERROR (Status);
//
- // Get the interrupt vector number corresponding to IRQ0 from the 8259 driver
+ // Install interrupt handler for Local APIC Timer
//
- TimerVector = 0;
- Status = mLegacy8259->GetVector (mLegacy8259, Efi8259Irq0, (UINT8 *) &TimerVector);
- ASSERT_EFI_ERROR (Status);
-
- //
- // Install interrupt handler for 8254 Timer #0 (ISA IRQ0)
- //
- Status = mCpu->RegisterInterruptHandler (mCpu, TimerVector, TimerInterruptHandler);
+ Status = mCpu->RegisterInterruptHandler (mCpu, LOCAL_APIC_TIMER_VECTOR,
+ TimerInterruptHandler);
ASSERT_EFI_ERROR (Status);
//
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 27/31] OvmfPkg/XenOvmf: Introduce XenTimerDxe
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
"PcAtChipsetPkg/8254TimerDxe" is replaced with a Xen-specific
EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
8259InterruptControllerDxe as it is not used anymore.
This Timer uses the local APIC timer as time source as it can work on
both a Xen PVH guest and an HVM one.
Based on the "PcAtChipsetPkg/8254TimerDxe" implementation.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
v2:
- Use InitializeApicTimer instead of WriteLocalApicReg
- rework comments (remove many that don't apply)
- remove unused includes, and libs
- have a macro to the timervector.
- cleanup, copyright
- rework calculation of TimerCount, value to be use by the APIC timer
- check for overflow of TimerPeriod, with the apic timer, the period can
be up to about 42s on Xen (or even higher by changing the DivideValue).
OvmfPkg/XenOvmf.dsc | 3 +-
OvmfPkg/XenOvmf.fdf | 3 +-
PcAtChipsetPkg/8254TimerDxe/8254Timer.inf => OvmfPkg/XenTimerDxe/XenTimerDxe.inf | 27 +++---
PcAtChipsetPkg/8254TimerDxe/Timer.h => OvmfPkg/XenTimerDxe/XenTimerDxe.h | 32 +++----
PcAtChipsetPkg/8254TimerDxe/Timer.c => OvmfPkg/XenTimerDxe/XenTimerDxe.c | 100 ++++++--------------
5 files changed, 55 insertions(+), 110 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 54601c697f..35af05715b 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -560,10 +560,9 @@ [Components]
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
- PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+ OvmfPkg/XenTimerDxe/XenTimerDxe.inf
UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
UefiCpuPkg/CpuDxe/CpuDxe.inf
- PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index f9e58befd6..d614bdce1d 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -284,10 +284,9 @@ [FV.DXEFV]
INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
INF MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+INF OvmfPkg/XenTimerDxe/XenTimerDxe.inf
INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
INF UefiCpuPkg/CpuDxe/CpuDxe.inf
-INF PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
INF OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
INF OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
diff --git a/PcAtChipsetPkg/8254TimerDxe/8254Timer.inf b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
similarity index 64%
copy from PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
copy to OvmfPkg/XenTimerDxe/XenTimerDxe.inf
index 46cf01de39..5ad80b9368 100644
--- a/PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
@@ -1,7 +1,9 @@
## @file
-# 8254 timer driver that provides Timer Arch protocol.
+# Local APIC timer driver that provides Timer Arch protocol.
+#
+# Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
#
-# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
# which accompanies this distribution. The full text of the license may be found at
@@ -14,9 +16,8 @@
[Defines]
INF_VERSION = 0x00010005
- BASE_NAME = Timer
- MODULE_UNI_FILE = Timer.uni
- FILE_GUID = f2765dec-6b41-11d5-8e71-00902707b35e
+ BASE_NAME = XenTimerDxe
+ FILE_GUID = 52fe8196-f9de-4d07-b22f-51f77a0e7c41
MODULE_TYPE = DXE_DRIVER
VERSION_STRING = 1.0
@@ -25,24 +26,24 @@ [Defines]
[Packages]
MdePkg/MdePkg.dec
IntelFrameworkPkg/IntelFrameworkPkg.dec
+ UefiCpuPkg/UefiCpuPkg.dec
+ OvmfPkg/OvmfPkg.dec
[LibraryClasses]
UefiBootServicesTableLib
BaseLib
DebugLib
UefiDriverEntryPoint
- IoLib
+ LocalApicLib
[Sources]
- Timer.h
- Timer.c
+ XenTimerDxe.h
+ XenTimerDxe.c
[Protocols]
gEfiCpuArchProtocolGuid ## CONSUMES
- gEfiLegacy8259ProtocolGuid ## CONSUMES
gEfiTimerArchProtocolGuid ## PRODUCES
-
+[Pcd]
+ gEfiMdePkgTokenSpaceGuid.PcdFSBClock ## CONSUMES
[Depex]
- gEfiCpuArchProtocolGuid AND gEfiLegacy8259ProtocolGuid
-[UserExtensions.TianoCore."ExtraFiles"]
- TimerExtra.uni
+ gEfiCpuArchProtocolGuid
diff --git a/PcAtChipsetPkg/8254TimerDxe/Timer.h b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
similarity index 89%
copy from PcAtChipsetPkg/8254TimerDxe/Timer.h
copy to OvmfPkg/XenTimerDxe/XenTimerDxe.h
index 9d70e3aa19..747259c162 100644
--- a/PcAtChipsetPkg/8254TimerDxe/Timer.h
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
@@ -1,7 +1,9 @@
/** @file
Private data structures
-Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -17,34 +19,24 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
#include <PiDxe.h>
#include <Protocol/Cpu.h>
-#include <Protocol/Legacy8259.h>
#include <Protocol/Timer.h>
+#include <Register/LocalApic.h>
+
#include <Library/UefiBootServicesTableLib.h>
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
-#include <Library/IoLib.h>
+#include <Library/LocalApicLib.h>
+#include <Library/PcdLib.h>
-//
-// The PCAT 8253/8254 has an input clock at 1.193182 MHz and Timer 0 is
-// initialized as a 16 bit free running counter that generates an interrupt(IRQ0)
-// each time the counter rolls over.
-//
-// 65536 counts
-// ---------------- * 1,000,000 uS/S = 54925.4 uS = 549254 * 100 ns
-// 1,193,182 Hz
-//
-
-//
-// The maximum tick duration for 8254 timer
-//
-#define MAX_TIMER_TICK_DURATION 549254
-//
// The default timer tick duration is set to 10 ms = 100000 100 ns units
//
#define DEFAULT_TIMER_TICK_DURATION 100000
-#define TIMER_CONTROL_PORT 0x43
-#define TIMER0_COUNT_PORT 0x40
+
+//
+// The Timer Vector use for interrupt
+//
+#define LOCAL_APIC_TIMER_VECTOR 32
//
// Function Prototypes
diff --git a/PcAtChipsetPkg/8254TimerDxe/Timer.c b/OvmfPkg/XenTimerDxe/XenTimerDxe.c
similarity index 77%
copy from PcAtChipsetPkg/8254TimerDxe/Timer.c
copy to OvmfPkg/XenTimerDxe/XenTimerDxe.c
index 60799aadd3..fb39ce0cd3 100644
--- a/PcAtChipsetPkg/8254TimerDxe/Timer.c
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.c
@@ -1,7 +1,9 @@
/** @file
Timer Architectural Protocol as defined in the DXE CIS
-Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2019, Citrix Systems, Inc.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -12,7 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
**/
-#include "Timer.h"
+#include "XenTimerDxe.h"
//
// The handle onto which the Timer Architectural Protocol will be installed
@@ -34,11 +36,6 @@ EFI_TIMER_ARCH_PROTOCOL mTimer = {
//
EFI_CPU_ARCH_PROTOCOL *mCpu;
-//
-// Pointer to the Legacy 8259 Protocol instance
-//
-EFI_LEGACY_8259_PROTOCOL *mLegacy8259;
-
//
// The notification function to call on every timer interrupt.
// A bug in the compiler prevents us from initializing this here.
@@ -54,22 +51,7 @@ volatile UINT64 mTimerPeriod = 0;
// Worker Functions
//
/**
- Sets the counter value for Timer #0 in a legacy 8254 timer.
-
- @param Count The 16-bit counter value to program into Timer #0 of the legacy 8254 timer.
-**/
-VOID
-SetPitCount (
- IN UINT16 Count
- )
-{
- IoWrite8 (TIMER_CONTROL_PORT, 0x36);
- IoWrite8 (TIMER0_COUNT_PORT, (UINT8)(Count & 0xff));
- IoWrite8 (TIMER0_COUNT_PORT, (UINT8)((Count >> 8) & 0xff));
-}
-
-/**
- 8254 Timer #0 Interrupt Handler.
+ Interrupt Handler.
@param InterruptType The type of interrupt that occurred
@param SystemContext A pointer to the system context when the interrupt occurred
@@ -85,7 +67,7 @@ TimerInterruptHandler (
OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
- mLegacy8259->EndOfInterrupt (mLegacy8259, Efi8259Irq0);
+ SendApicEoi();
if (mTimerNotifyFunction != NULL) {
//
@@ -187,49 +169,41 @@ TimerDriverSetTimerPeriod (
)
{
UINT64 TimerCount;
+ UINT32 TimerFrequency;
+ UINTN DivideValue = 1;
- //
- // The basic clock is 1.19318 MHz or 0.119318 ticks per 100 ns.
- // TimerPeriod * 0.119318 = 8254 timer divisor. Using integer arithmetic
- // TimerCount = (TimerPeriod * 119318)/1000000.
- //
- // Round up to next highest integer. This guarantees that the timer is
- // equal to or slightly longer than the requested time.
- // TimerCount = ((TimerPeriod * 119318) + 500000)/1000000
- //
- // Note that a TimerCount of 0 is equivalent to a count of 65,536
- //
- // Since TimerCount is limited to 16 bits for IA32, TimerPeriod is limited
- // to 20 bits.
- //
if (TimerPeriod == 0) {
//
// Disable timer interrupt for a TimerPeriod of 0
//
- mLegacy8259->DisableIrq (mLegacy8259, Efi8259Irq0);
+ DisableApicTimerInterrupt();
} else {
+ TimerFrequency = PcdGet32(PcdFSBClock) / DivideValue;
//
- // Convert TimerPeriod into 8254 counts
+ // Convert TimerPeriod into local APIC counts
//
- TimerCount = DivU64x32 (MultU64x32 (119318, (UINT32) TimerPeriod) + 500000, 1000000);
+ // TimerPeriod is in 100ns
+ // TimerPeriod/10000000 will be in seconds.
+ TimerCount = DivU64x32 (MultU64x32 (TimerPeriod, TimerFrequency),
+ 10000000);
- //
// Check for overflow
- //
- if (TimerCount >= 65536) {
- TimerCount = 0;
- TimerPeriod = MAX_TIMER_TICK_DURATION;
+ if (TimerCount > MAX_UINT32) {
+ TimerCount = MAX_UINT32;
+ /* TimerPeriod = (MAX_UINT32 / TimerFrequency) * 10000000; */
+ TimerPeriod = 429496730;
}
+
//
- // Program the 8254 timer with the new count value
+ // Program the timer with the new count value
//
- SetPitCount ((UINT16) TimerCount);
+ InitializeApicTimer(DivideValue, TimerCount, TRUE, LOCAL_APIC_TIMER_VECTOR);
//
// Enable timer interrupt
//
- mLegacy8259->EnableIrq (mLegacy8259, Efi8259Irq0, FALSE);
+ EnableApicTimerInterrupt();
}
//
// Save the new timer period
@@ -294,16 +268,9 @@ TimerDriverGenerateSoftInterrupt (
IN EFI_TIMER_ARCH_PROTOCOL *This
)
{
- EFI_STATUS Status;
- UINT16 IRQMask;
EFI_TPL OriginalTPL;
- //
- // If the timer interrupt is enabled, then the registered handler will be invoked.
- //
- Status = mLegacy8259->GetMask (mLegacy8259, NULL, NULL, &IRQMask, NULL);
- ASSERT_EFI_ERROR (Status);
- if ((IRQMask & 0x1) == 0) {
+ if (GetApicTimerInterruptState()) {
//
// Invoke the registered handler
//
@@ -343,7 +310,6 @@ TimerDriverInitialize (
)
{
EFI_STATUS Status;
- UINT32 TimerVector;
//
// Initialize the pointer to our notify function.
@@ -361,12 +327,6 @@ TimerDriverInitialize (
Status = gBS->LocateProtocol (&gEfiCpuArchProtocolGuid, NULL, (VOID **) &mCpu);
ASSERT_EFI_ERROR (Status);
- //
- // Find the Legacy8259 protocol.
- //
- Status = gBS->LocateProtocol (&gEfiLegacy8259ProtocolGuid, NULL, (VOID **) &mLegacy8259);
- ASSERT_EFI_ERROR (Status);
-
//
// Force the timer to be disabled
//
@@ -374,16 +334,10 @@ TimerDriverInitialize (
ASSERT_EFI_ERROR (Status);
//
- // Get the interrupt vector number corresponding to IRQ0 from the 8259 driver
+ // Install interrupt handler for Local APIC Timer
//
- TimerVector = 0;
- Status = mLegacy8259->GetVector (mLegacy8259, Efi8259Irq0, (UINT8 *) &TimerVector);
- ASSERT_EFI_ERROR (Status);
-
- //
- // Install interrupt handler for 8254 Timer #0 (ISA IRQ0)
- //
- Status = mCpu->RegisterInterruptHandler (mCpu, TimerVector, TimerInterruptHandler);
+ Status = mCpu->RegisterInterruptHandler (mCpu, LOCAL_APIC_TIMER_VECTOR,
+ TimerInterruptHandler);
ASSERT_EFI_ERROR (Status);
//
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 27/31] OvmfPkg/XenOvmf: Introduce XenTimerDxe
@ 2019-04-15 14:07 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 14:07 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> "PcAtChipsetPkg/8254TimerDxe" is replaced with a Xen-specific
> EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
> 8259InterruptControllerDxe as it is not used anymore.
>
> This Timer uses the local APIC timer as time source as it can work on
> both a Xen PVH guest and an HVM one.
>
> Based on the "PcAtChipsetPkg/8254TimerDxe" implementation.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> v2:
> - Use InitializeApicTimer instead of WriteLocalApicReg
> - rework comments (remove many that don't apply)
> - remove unused includes, and libs
> - have a macro to the timervector.
> - cleanup, copyright
> - rework calculation of TimerCount, value to be use by the APIC timer
> - check for overflow of TimerPeriod, with the apic timer, the period can
> be up to about 42s on Xen (or even higher by changing the DivideValue).
>
> OvmfPkg/XenOvmf.dsc | 3 +-
> OvmfPkg/XenOvmf.fdf | 3 +-
> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf => OvmfPkg/XenTimerDxe/XenTimerDxe.inf | 27 +++---
> PcAtChipsetPkg/8254TimerDxe/Timer.h => OvmfPkg/XenTimerDxe/XenTimerDxe.h | 32 +++----
> PcAtChipsetPkg/8254TimerDxe/Timer.c => OvmfPkg/XenTimerDxe/XenTimerDxe.c | 100 ++++++--------------
> 5 files changed, 55 insertions(+), 110 deletions(-)
For OVMF in general, the primary residence of 8254TimerDxe is now under
OvmfPkg, due to <https://bugzilla.tianocore.org/show_bug.cgi?id=1496>.
However, as long as the module continues to exist under PcAtChipsetPkg
(i.e. until <https://bugzilla.tianocore.org/show_bug.cgi?id=1604> is
completed), I think it is OK as the copy-origin here.
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 54601c697f..35af05715b 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -560,10 +560,9 @@ [Components]
> MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>
> MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> - PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> + OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
> UefiCpuPkg/CpuDxe/CpuDxe.inf
> - PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
> OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index f9e58befd6..d614bdce1d 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -284,10 +284,9 @@ [FV.DXEFV]
> INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
> INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
> INF MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +INF OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
> INF UefiCpuPkg/CpuDxe/CpuDxe.inf
> -INF PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> INF OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
> INF OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
> INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> diff --git a/PcAtChipsetPkg/8254TimerDxe/8254Timer.inf b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> similarity index 64%
> copy from PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> copy to OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> index 46cf01de39..5ad80b9368 100644
> --- a/PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> @@ -1,7 +1,9 @@
> ## @file
> -# 8254 timer driver that provides Timer Arch protocol.
> +# Local APIC timer driver that provides Timer Arch protocol.
> +#
> +# Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.<BR>
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> -# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> # which accompanies this distribution. The full text of the license may be found at
I'm sure this is well-intended (you simply created the patch before the
Intel copyright notice was bumped under PcAtChipsetPkg), but now this
diff appears a bit questionable, due to "downgrading" the Intel
copyright. I understand it's technically correct (because the original
code, being copied & customized here, matches the copyright notice too).
(1) Still, could you please refresh this patch so that the Intel
copyright is not touched in the "find-copies-harder" diff? (Covering all
new files added in this patch.)
... Such a refresh would be justified by
<https://bugzilla.tianocore.org/show_bug.cgi?id=1373> anyway -- we
should preferably add new files only with SPDX license IDs now.
Otherwise I'd be OK to ACK the patch.
Thanks
Laszlo
> @@ -14,9 +16,8 @@
>
> [Defines]
> INF_VERSION = 0x00010005
> - BASE_NAME = Timer
> - MODULE_UNI_FILE = Timer.uni
> - FILE_GUID = f2765dec-6b41-11d5-8e71-00902707b35e
> + BASE_NAME = XenTimerDxe
> + FILE_GUID = 52fe8196-f9de-4d07-b22f-51f77a0e7c41
> MODULE_TYPE = DXE_DRIVER
> VERSION_STRING = 1.0
>
> @@ -25,24 +26,24 @@ [Defines]
> [Packages]
> MdePkg/MdePkg.dec
> IntelFrameworkPkg/IntelFrameworkPkg.dec
> + UefiCpuPkg/UefiCpuPkg.dec
> + OvmfPkg/OvmfPkg.dec
>
> [LibraryClasses]
> UefiBootServicesTableLib
> BaseLib
> DebugLib
> UefiDriverEntryPoint
> - IoLib
> + LocalApicLib
>
> [Sources]
> - Timer.h
> - Timer.c
> + XenTimerDxe.h
> + XenTimerDxe.c
>
> [Protocols]
> gEfiCpuArchProtocolGuid ## CONSUMES
> - gEfiLegacy8259ProtocolGuid ## CONSUMES
> gEfiTimerArchProtocolGuid ## PRODUCES
> -
> +[Pcd]
> + gEfiMdePkgTokenSpaceGuid.PcdFSBClock ## CONSUMES
> [Depex]
> - gEfiCpuArchProtocolGuid AND gEfiLegacy8259ProtocolGuid
> -[UserExtensions.TianoCore."ExtraFiles"]
> - TimerExtra.uni
> + gEfiCpuArchProtocolGuid
> diff --git a/PcAtChipsetPkg/8254TimerDxe/Timer.h b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
> similarity index 89%
> copy from PcAtChipsetPkg/8254TimerDxe/Timer.h
> copy to OvmfPkg/XenTimerDxe/XenTimerDxe.h
> index 9d70e3aa19..747259c162 100644
> --- a/PcAtChipsetPkg/8254TimerDxe/Timer.h
> +++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
> @@ -1,7 +1,9 @@
> /** @file
> Private data structures
>
> -Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
> +Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.<BR>
> +Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> @@ -17,34 +19,24 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> #include <PiDxe.h>
>
> #include <Protocol/Cpu.h>
> -#include <Protocol/Legacy8259.h>
> #include <Protocol/Timer.h>
>
> +#include <Register/LocalApic.h>
> +
> #include <Library/UefiBootServicesTableLib.h>
> #include <Library/BaseLib.h>
> #include <Library/DebugLib.h>
> -#include <Library/IoLib.h>
> +#include <Library/LocalApicLib.h>
> +#include <Library/PcdLib.h>
>
> -//
> -// The PCAT 8253/8254 has an input clock at 1.193182 MHz and Timer 0 is
> -// initialized as a 16 bit free running counter that generates an interrupt(IRQ0)
> -// each time the counter rolls over.
> -//
> -// 65536 counts
> -// ---------------- * 1,000,000 uS/S = 54925.4 uS = 549254 * 100 ns
> -// 1,193,182 Hz
> -//
> -
> -//
> -// The maximum tick duration for 8254 timer
> -//
> -#define MAX_TIMER_TICK_DURATION 549254
> -//
> // The default timer tick duration is set to 10 ms = 100000 100 ns units
> //
> #define DEFAULT_TIMER_TICK_DURATION 100000
> -#define TIMER_CONTROL_PORT 0x43
> -#define TIMER0_COUNT_PORT 0x40
> +
> +//
> +// The Timer Vector use for interrupt
> +//
> +#define LOCAL_APIC_TIMER_VECTOR 32
>
> //
> // Function Prototypes
> diff --git a/PcAtChipsetPkg/8254TimerDxe/Timer.c b/OvmfPkg/XenTimerDxe/XenTimerDxe.c
> similarity index 77%
> copy from PcAtChipsetPkg/8254TimerDxe/Timer.c
> copy to OvmfPkg/XenTimerDxe/XenTimerDxe.c
> index 60799aadd3..fb39ce0cd3 100644
> --- a/PcAtChipsetPkg/8254TimerDxe/Timer.c
> +++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.c
> @@ -1,7 +1,9 @@
> /** @file
> Timer Architectural Protocol as defined in the DXE CIS
>
> -Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
> +Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.<BR>
> +Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> @@ -12,7 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>
> **/
>
> -#include "Timer.h"
> +#include "XenTimerDxe.h"
>
> //
> // The handle onto which the Timer Architectural Protocol will be installed
> @@ -34,11 +36,6 @@ EFI_TIMER_ARCH_PROTOCOL mTimer = {
> //
> EFI_CPU_ARCH_PROTOCOL *mCpu;
>
> -//
> -// Pointer to the Legacy 8259 Protocol instance
> -//
> -EFI_LEGACY_8259_PROTOCOL *mLegacy8259;
> -
> //
> // The notification function to call on every timer interrupt.
> // A bug in the compiler prevents us from initializing this here.
> @@ -54,22 +51,7 @@ volatile UINT64 mTimerPeriod = 0;
> // Worker Functions
> //
> /**
> - Sets the counter value for Timer #0 in a legacy 8254 timer.
> -
> - @param Count The 16-bit counter value to program into Timer #0 of the legacy 8254 timer.
> -**/
> -VOID
> -SetPitCount (
> - IN UINT16 Count
> - )
> -{
> - IoWrite8 (TIMER_CONTROL_PORT, 0x36);
> - IoWrite8 (TIMER0_COUNT_PORT, (UINT8)(Count & 0xff));
> - IoWrite8 (TIMER0_COUNT_PORT, (UINT8)((Count >> 8) & 0xff));
> -}
> -
> -/**
> - 8254 Timer #0 Interrupt Handler.
> + Interrupt Handler.
>
> @param InterruptType The type of interrupt that occurred
> @param SystemContext A pointer to the system context when the interrupt occurred
> @@ -85,7 +67,7 @@ TimerInterruptHandler (
>
> OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
>
> - mLegacy8259->EndOfInterrupt (mLegacy8259, Efi8259Irq0);
> + SendApicEoi();
>
> if (mTimerNotifyFunction != NULL) {
> //
> @@ -187,49 +169,41 @@ TimerDriverSetTimerPeriod (
> )
> {
> UINT64 TimerCount;
> + UINT32 TimerFrequency;
> + UINTN DivideValue = 1;
>
> - //
> - // The basic clock is 1.19318 MHz or 0.119318 ticks per 100 ns.
> - // TimerPeriod * 0.119318 = 8254 timer divisor. Using integer arithmetic
> - // TimerCount = (TimerPeriod * 119318)/1000000.
> - //
> - // Round up to next highest integer. This guarantees that the timer is
> - // equal to or slightly longer than the requested time.
> - // TimerCount = ((TimerPeriod * 119318) + 500000)/1000000
> - //
> - // Note that a TimerCount of 0 is equivalent to a count of 65,536
> - //
> - // Since TimerCount is limited to 16 bits for IA32, TimerPeriod is limited
> - // to 20 bits.
> - //
> if (TimerPeriod == 0) {
> //
> // Disable timer interrupt for a TimerPeriod of 0
> //
> - mLegacy8259->DisableIrq (mLegacy8259, Efi8259Irq0);
> + DisableApicTimerInterrupt();
> } else {
> + TimerFrequency = PcdGet32(PcdFSBClock) / DivideValue;
>
> //
> - // Convert TimerPeriod into 8254 counts
> + // Convert TimerPeriod into local APIC counts
> //
> - TimerCount = DivU64x32 (MultU64x32 (119318, (UINT32) TimerPeriod) + 500000, 1000000);
> + // TimerPeriod is in 100ns
> + // TimerPeriod/10000000 will be in seconds.
> + TimerCount = DivU64x32 (MultU64x32 (TimerPeriod, TimerFrequency),
> + 10000000);
>
> - //
> // Check for overflow
> - //
> - if (TimerCount >= 65536) {
> - TimerCount = 0;
> - TimerPeriod = MAX_TIMER_TICK_DURATION;
> + if (TimerCount > MAX_UINT32) {
> + TimerCount = MAX_UINT32;
> + /* TimerPeriod = (MAX_UINT32 / TimerFrequency) * 10000000; */
> + TimerPeriod = 429496730;
> }
> +
> //
> - // Program the 8254 timer with the new count value
> + // Program the timer with the new count value
> //
> - SetPitCount ((UINT16) TimerCount);
> + InitializeApicTimer(DivideValue, TimerCount, TRUE, LOCAL_APIC_TIMER_VECTOR);
>
> //
> // Enable timer interrupt
> //
> - mLegacy8259->EnableIrq (mLegacy8259, Efi8259Irq0, FALSE);
> + EnableApicTimerInterrupt();
> }
> //
> // Save the new timer period
> @@ -294,16 +268,9 @@ TimerDriverGenerateSoftInterrupt (
> IN EFI_TIMER_ARCH_PROTOCOL *This
> )
> {
> - EFI_STATUS Status;
> - UINT16 IRQMask;
> EFI_TPL OriginalTPL;
>
> - //
> - // If the timer interrupt is enabled, then the registered handler will be invoked.
> - //
> - Status = mLegacy8259->GetMask (mLegacy8259, NULL, NULL, &IRQMask, NULL);
> - ASSERT_EFI_ERROR (Status);
> - if ((IRQMask & 0x1) == 0) {
> + if (GetApicTimerInterruptState()) {
> //
> // Invoke the registered handler
> //
> @@ -343,7 +310,6 @@ TimerDriverInitialize (
> )
> {
> EFI_STATUS Status;
> - UINT32 TimerVector;
>
> //
> // Initialize the pointer to our notify function.
> @@ -361,12 +327,6 @@ TimerDriverInitialize (
> Status = gBS->LocateProtocol (&gEfiCpuArchProtocolGuid, NULL, (VOID **) &mCpu);
> ASSERT_EFI_ERROR (Status);
>
> - //
> - // Find the Legacy8259 protocol.
> - //
> - Status = gBS->LocateProtocol (&gEfiLegacy8259ProtocolGuid, NULL, (VOID **) &mLegacy8259);
> - ASSERT_EFI_ERROR (Status);
> -
> //
> // Force the timer to be disabled
> //
> @@ -374,16 +334,10 @@ TimerDriverInitialize (
> ASSERT_EFI_ERROR (Status);
>
> //
> - // Get the interrupt vector number corresponding to IRQ0 from the 8259 driver
> + // Install interrupt handler for Local APIC Timer
> //
> - TimerVector = 0;
> - Status = mLegacy8259->GetVector (mLegacy8259, Efi8259Irq0, (UINT8 *) &TimerVector);
> - ASSERT_EFI_ERROR (Status);
> -
> - //
> - // Install interrupt handler for 8254 Timer #0 (ISA IRQ0)
> - //
> - Status = mCpu->RegisterInterruptHandler (mCpu, TimerVector, TimerInterruptHandler);
> + Status = mCpu->RegisterInterruptHandler (mCpu, LOCAL_APIC_TIMER_VECTOR,
> + TimerInterruptHandler);
> ASSERT_EFI_ERROR (Status);
>
> //
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 27/31] OvmfPkg/XenOvmf: Introduce XenTimerDxe
@ 2019-04-15 14:07 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 14:07 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> "PcAtChipsetPkg/8254TimerDxe" is replaced with a Xen-specific
> EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
> 8259InterruptControllerDxe as it is not used anymore.
>
> This Timer uses the local APIC timer as time source as it can work on
> both a Xen PVH guest and an HVM one.
>
> Based on the "PcAtChipsetPkg/8254TimerDxe" implementation.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> v2:
> - Use InitializeApicTimer instead of WriteLocalApicReg
> - rework comments (remove many that don't apply)
> - remove unused includes, and libs
> - have a macro to the timervector.
> - cleanup, copyright
> - rework calculation of TimerCount, value to be use by the APIC timer
> - check for overflow of TimerPeriod, with the apic timer, the period can
> be up to about 42s on Xen (or even higher by changing the DivideValue).
>
> OvmfPkg/XenOvmf.dsc | 3 +-
> OvmfPkg/XenOvmf.fdf | 3 +-
> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf => OvmfPkg/XenTimerDxe/XenTimerDxe.inf | 27 +++---
> PcAtChipsetPkg/8254TimerDxe/Timer.h => OvmfPkg/XenTimerDxe/XenTimerDxe.h | 32 +++----
> PcAtChipsetPkg/8254TimerDxe/Timer.c => OvmfPkg/XenTimerDxe/XenTimerDxe.c | 100 ++++++--------------
> 5 files changed, 55 insertions(+), 110 deletions(-)
For OVMF in general, the primary residence of 8254TimerDxe is now under
OvmfPkg, due to <https://bugzilla.tianocore.org/show_bug.cgi?id=1496>.
However, as long as the module continues to exist under PcAtChipsetPkg
(i.e. until <https://bugzilla.tianocore.org/show_bug.cgi?id=1604> is
completed), I think it is OK as the copy-origin here.
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 54601c697f..35af05715b 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -560,10 +560,9 @@ [Components]
> MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>
> MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> - PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> + OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
> UefiCpuPkg/CpuDxe/CpuDxe.inf
> - PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
> OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index f9e58befd6..d614bdce1d 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -284,10 +284,9 @@ [FV.DXEFV]
> INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
> INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
> INF MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +INF OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
> INF UefiCpuPkg/CpuDxe/CpuDxe.inf
> -INF PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> INF OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
> INF OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
> INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> diff --git a/PcAtChipsetPkg/8254TimerDxe/8254Timer.inf b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> similarity index 64%
> copy from PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> copy to OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> index 46cf01de39..5ad80b9368 100644
> --- a/PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> @@ -1,7 +1,9 @@
> ## @file
> -# 8254 timer driver that provides Timer Arch protocol.
> +# Local APIC timer driver that provides Timer Arch protocol.
> +#
> +# Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.<BR>
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> -# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> # which accompanies this distribution. The full text of the license may be found at
I'm sure this is well-intended (you simply created the patch before the
Intel copyright notice was bumped under PcAtChipsetPkg), but now this
diff appears a bit questionable, due to "downgrading" the Intel
copyright. I understand it's technically correct (because the original
code, being copied & customized here, matches the copyright notice too).
(1) Still, could you please refresh this patch so that the Intel
copyright is not touched in the "find-copies-harder" diff? (Covering all
new files added in this patch.)
... Such a refresh would be justified by
<https://bugzilla.tianocore.org/show_bug.cgi?id=1373> anyway -- we
should preferably add new files only with SPDX license IDs now.
Otherwise I'd be OK to ACK the patch.
Thanks
Laszlo
> @@ -14,9 +16,8 @@
>
> [Defines]
> INF_VERSION = 0x00010005
> - BASE_NAME = Timer
> - MODULE_UNI_FILE = Timer.uni
> - FILE_GUID = f2765dec-6b41-11d5-8e71-00902707b35e
> + BASE_NAME = XenTimerDxe
> + FILE_GUID = 52fe8196-f9de-4d07-b22f-51f77a0e7c41
> MODULE_TYPE = DXE_DRIVER
> VERSION_STRING = 1.0
>
> @@ -25,24 +26,24 @@ [Defines]
> [Packages]
> MdePkg/MdePkg.dec
> IntelFrameworkPkg/IntelFrameworkPkg.dec
> + UefiCpuPkg/UefiCpuPkg.dec
> + OvmfPkg/OvmfPkg.dec
>
> [LibraryClasses]
> UefiBootServicesTableLib
> BaseLib
> DebugLib
> UefiDriverEntryPoint
> - IoLib
> + LocalApicLib
>
> [Sources]
> - Timer.h
> - Timer.c
> + XenTimerDxe.h
> + XenTimerDxe.c
>
> [Protocols]
> gEfiCpuArchProtocolGuid ## CONSUMES
> - gEfiLegacy8259ProtocolGuid ## CONSUMES
> gEfiTimerArchProtocolGuid ## PRODUCES
> -
> +[Pcd]
> + gEfiMdePkgTokenSpaceGuid.PcdFSBClock ## CONSUMES
> [Depex]
> - gEfiCpuArchProtocolGuid AND gEfiLegacy8259ProtocolGuid
> -[UserExtensions.TianoCore."ExtraFiles"]
> - TimerExtra.uni
> + gEfiCpuArchProtocolGuid
> diff --git a/PcAtChipsetPkg/8254TimerDxe/Timer.h b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
> similarity index 89%
> copy from PcAtChipsetPkg/8254TimerDxe/Timer.h
> copy to OvmfPkg/XenTimerDxe/XenTimerDxe.h
> index 9d70e3aa19..747259c162 100644
> --- a/PcAtChipsetPkg/8254TimerDxe/Timer.h
> +++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
> @@ -1,7 +1,9 @@
> /** @file
> Private data structures
>
> -Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
> +Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.<BR>
> +Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> @@ -17,34 +19,24 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> #include <PiDxe.h>
>
> #include <Protocol/Cpu.h>
> -#include <Protocol/Legacy8259.h>
> #include <Protocol/Timer.h>
>
> +#include <Register/LocalApic.h>
> +
> #include <Library/UefiBootServicesTableLib.h>
> #include <Library/BaseLib.h>
> #include <Library/DebugLib.h>
> -#include <Library/IoLib.h>
> +#include <Library/LocalApicLib.h>
> +#include <Library/PcdLib.h>
>
> -//
> -// The PCAT 8253/8254 has an input clock at 1.193182 MHz and Timer 0 is
> -// initialized as a 16 bit free running counter that generates an interrupt(IRQ0)
> -// each time the counter rolls over.
> -//
> -// 65536 counts
> -// ---------------- * 1,000,000 uS/S = 54925.4 uS = 549254 * 100 ns
> -// 1,193,182 Hz
> -//
> -
> -//
> -// The maximum tick duration for 8254 timer
> -//
> -#define MAX_TIMER_TICK_DURATION 549254
> -//
> // The default timer tick duration is set to 10 ms = 100000 100 ns units
> //
> #define DEFAULT_TIMER_TICK_DURATION 100000
> -#define TIMER_CONTROL_PORT 0x43
> -#define TIMER0_COUNT_PORT 0x40
> +
> +//
> +// The Timer Vector use for interrupt
> +//
> +#define LOCAL_APIC_TIMER_VECTOR 32
>
> //
> // Function Prototypes
> diff --git a/PcAtChipsetPkg/8254TimerDxe/Timer.c b/OvmfPkg/XenTimerDxe/XenTimerDxe.c
> similarity index 77%
> copy from PcAtChipsetPkg/8254TimerDxe/Timer.c
> copy to OvmfPkg/XenTimerDxe/XenTimerDxe.c
> index 60799aadd3..fb39ce0cd3 100644
> --- a/PcAtChipsetPkg/8254TimerDxe/Timer.c
> +++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.c
> @@ -1,7 +1,9 @@
> /** @file
> Timer Architectural Protocol as defined in the DXE CIS
>
> -Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
> +Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.<BR>
> +Copyright (c) 2019, Citrix Systems, Inc.
> +
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD License
> which accompanies this distribution. The full text of the license may be found at
> @@ -12,7 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>
> **/
>
> -#include "Timer.h"
> +#include "XenTimerDxe.h"
>
> //
> // The handle onto which the Timer Architectural Protocol will be installed
> @@ -34,11 +36,6 @@ EFI_TIMER_ARCH_PROTOCOL mTimer = {
> //
> EFI_CPU_ARCH_PROTOCOL *mCpu;
>
> -//
> -// Pointer to the Legacy 8259 Protocol instance
> -//
> -EFI_LEGACY_8259_PROTOCOL *mLegacy8259;
> -
> //
> // The notification function to call on every timer interrupt.
> // A bug in the compiler prevents us from initializing this here.
> @@ -54,22 +51,7 @@ volatile UINT64 mTimerPeriod = 0;
> // Worker Functions
> //
> /**
> - Sets the counter value for Timer #0 in a legacy 8254 timer.
> -
> - @param Count The 16-bit counter value to program into Timer #0 of the legacy 8254 timer.
> -**/
> -VOID
> -SetPitCount (
> - IN UINT16 Count
> - )
> -{
> - IoWrite8 (TIMER_CONTROL_PORT, 0x36);
> - IoWrite8 (TIMER0_COUNT_PORT, (UINT8)(Count & 0xff));
> - IoWrite8 (TIMER0_COUNT_PORT, (UINT8)((Count >> 8) & 0xff));
> -}
> -
> -/**
> - 8254 Timer #0 Interrupt Handler.
> + Interrupt Handler.
>
> @param InterruptType The type of interrupt that occurred
> @param SystemContext A pointer to the system context when the interrupt occurred
> @@ -85,7 +67,7 @@ TimerInterruptHandler (
>
> OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
>
> - mLegacy8259->EndOfInterrupt (mLegacy8259, Efi8259Irq0);
> + SendApicEoi();
>
> if (mTimerNotifyFunction != NULL) {
> //
> @@ -187,49 +169,41 @@ TimerDriverSetTimerPeriod (
> )
> {
> UINT64 TimerCount;
> + UINT32 TimerFrequency;
> + UINTN DivideValue = 1;
>
> - //
> - // The basic clock is 1.19318 MHz or 0.119318 ticks per 100 ns.
> - // TimerPeriod * 0.119318 = 8254 timer divisor. Using integer arithmetic
> - // TimerCount = (TimerPeriod * 119318)/1000000.
> - //
> - // Round up to next highest integer. This guarantees that the timer is
> - // equal to or slightly longer than the requested time.
> - // TimerCount = ((TimerPeriod * 119318) + 500000)/1000000
> - //
> - // Note that a TimerCount of 0 is equivalent to a count of 65,536
> - //
> - // Since TimerCount is limited to 16 bits for IA32, TimerPeriod is limited
> - // to 20 bits.
> - //
> if (TimerPeriod == 0) {
> //
> // Disable timer interrupt for a TimerPeriod of 0
> //
> - mLegacy8259->DisableIrq (mLegacy8259, Efi8259Irq0);
> + DisableApicTimerInterrupt();
> } else {
> + TimerFrequency = PcdGet32(PcdFSBClock) / DivideValue;
>
> //
> - // Convert TimerPeriod into 8254 counts
> + // Convert TimerPeriod into local APIC counts
> //
> - TimerCount = DivU64x32 (MultU64x32 (119318, (UINT32) TimerPeriod) + 500000, 1000000);
> + // TimerPeriod is in 100ns
> + // TimerPeriod/10000000 will be in seconds.
> + TimerCount = DivU64x32 (MultU64x32 (TimerPeriod, TimerFrequency),
> + 10000000);
>
> - //
> // Check for overflow
> - //
> - if (TimerCount >= 65536) {
> - TimerCount = 0;
> - TimerPeriod = MAX_TIMER_TICK_DURATION;
> + if (TimerCount > MAX_UINT32) {
> + TimerCount = MAX_UINT32;
> + /* TimerPeriod = (MAX_UINT32 / TimerFrequency) * 10000000; */
> + TimerPeriod = 429496730;
> }
> +
> //
> - // Program the 8254 timer with the new count value
> + // Program the timer with the new count value
> //
> - SetPitCount ((UINT16) TimerCount);
> + InitializeApicTimer(DivideValue, TimerCount, TRUE, LOCAL_APIC_TIMER_VECTOR);
>
> //
> // Enable timer interrupt
> //
> - mLegacy8259->EnableIrq (mLegacy8259, Efi8259Irq0, FALSE);
> + EnableApicTimerInterrupt();
> }
> //
> // Save the new timer period
> @@ -294,16 +268,9 @@ TimerDriverGenerateSoftInterrupt (
> IN EFI_TIMER_ARCH_PROTOCOL *This
> )
> {
> - EFI_STATUS Status;
> - UINT16 IRQMask;
> EFI_TPL OriginalTPL;
>
> - //
> - // If the timer interrupt is enabled, then the registered handler will be invoked.
> - //
> - Status = mLegacy8259->GetMask (mLegacy8259, NULL, NULL, &IRQMask, NULL);
> - ASSERT_EFI_ERROR (Status);
> - if ((IRQMask & 0x1) == 0) {
> + if (GetApicTimerInterruptState()) {
> //
> // Invoke the registered handler
> //
> @@ -343,7 +310,6 @@ TimerDriverInitialize (
> )
> {
> EFI_STATUS Status;
> - UINT32 TimerVector;
>
> //
> // Initialize the pointer to our notify function.
> @@ -361,12 +327,6 @@ TimerDriverInitialize (
> Status = gBS->LocateProtocol (&gEfiCpuArchProtocolGuid, NULL, (VOID **) &mCpu);
> ASSERT_EFI_ERROR (Status);
>
> - //
> - // Find the Legacy8259 protocol.
> - //
> - Status = gBS->LocateProtocol (&gEfiLegacy8259ProtocolGuid, NULL, (VOID **) &mLegacy8259);
> - ASSERT_EFI_ERROR (Status);
> -
> //
> // Force the timer to be disabled
> //
> @@ -374,16 +334,10 @@ TimerDriverInitialize (
> ASSERT_EFI_ERROR (Status);
>
> //
> - // Get the interrupt vector number corresponding to IRQ0 from the 8259 driver
> + // Install interrupt handler for Local APIC Timer
> //
> - TimerVector = 0;
> - Status = mLegacy8259->GetVector (mLegacy8259, Efi8259Irq0, (UINT8 *) &TimerVector);
> - ASSERT_EFI_ERROR (Status);
> -
> - //
> - // Install interrupt handler for 8254 Timer #0 (ISA IRQ0)
> - //
> - Status = mCpu->RegisterInterruptHandler (mCpu, TimerVector, TimerInterruptHandler);
> + Status = mCpu->RegisterInterruptHandler (mCpu, LOCAL_APIC_TIMER_VECTOR,
> + TimerInterruptHandler);
> ASSERT_EFI_ERROR (Status);
>
> //
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 28/31] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
On a Xen PVH guest, none of the existing serial or console interface
works, so we add a new one, based on XenConsoleSerialPortLib, and
implemeted via SerialDxe.
That a simple console implementation that can works on both PVH guest
and HVM guests, even if it rarely going to be use on HVM.
Have PlatformBootManagerLib look for the new console, when running as a
Xen guest.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
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/XenOvmf.dsc | 4 ++
OvmfPkg/XenOvmf.fdf | 1 +
OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 4 ++
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h | 1 +
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 10 +++-
OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c | 59 ++++++++++++++++++++
6 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 35af05715b..a26f611058 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -599,6 +599,10 @@ [Components]
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+ MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
+ <LibraryClasses>
+ 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/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index d614bdce1d..e078c7b405 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -298,6 +298,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 c41aaeef3f..7dd0683cd2 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -67,6 +67,10 @@ [Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile
+ 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 4948ca6518..2ab1a76f6a 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
@@ -172,6 +172,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 1a6d47732e..f186060f34 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -85,6 +85,13 @@ InstallDevicePathCallback (
VOID
);
+STATIC
+BOOLEAN
+XenDetected (
+ VOID
+ );
+
+
VOID
PlatformRegisterFvBootOption (
EFI_GUID *FileGuid,
@@ -404,7 +411,8 @@ PlatformBootManagerBeforeConsole (
//
EfiBootManagerDispatchDeferredImages ();
- PlatformInitializeConsole (gPlatformConsole);
+ PlatformInitializeConsole (
+ XenDetected() ? gXenPlatformConsole : gPlatformConsole);
PcdStatus = PcdSet16S (PcdPlatformBootTimeOut,
GetFrontPageTimeoutFromQemu ());
ASSERT_RETURN_ERROR (PcdStatus);
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
index 1250a6d351..4179370c81 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
@@ -16,6 +16,11 @@
#include "BdsPlatform.h"
#include <Guid/QemuRamfb.h>
+#define SERIAL_DXE_FILE_GUID { \
+ 0xD3987D4B, 0x971A, 0x435F, \
+ { 0x8C, 0xAF, 0x49, 0x67, 0xEB, 0x62, 0x72, 0x41 } \
+ }
+
//
// Debug Agent UART Device Path structure
//
@@ -49,6 +54,18 @@ typedef struct {
} VENDOR_RAMFB_DEVICE_PATH;
#pragma pack ()
+//
+// Xen Console Device Path structure
+//
+#pragma pack(1)
+typedef struct {
+ VENDOR_DEVICE_PATH VendorHardware;
+ UART_DEVICE_PATH Uart;
+ VENDOR_DEVICE_PATH TerminalType;
+ EFI_DEVICE_PATH_PROTOCOL End;
+} XEN_CONSOLE_DEVICE_PATH;
+#pragma pack()
+
ACPI_HID_DEVICE_PATH gPnpPs2KeyboardDeviceNode = gPnpPs2Keyboard;
ACPI_HID_DEVICE_PATH gPnp16550ComPortDeviceNode = gPnp16550ComPort;
UART_DEVICE_PATH gUartDeviceNode = gUart;
@@ -147,6 +164,37 @@ STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = {
gEndEntire
};
+STATIC XEN_CONSOLE_DEVICE_PATH gXenConsoleDevicePath = {
+ {
+ {
+ HARDWARE_DEVICE_PATH,
+ HW_VENDOR_DP,
+ {
+ (UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+ (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+ }
+ },
+ SERIAL_DXE_FILE_GUID
+ },
+ {
+ {
+ MESSAGING_DEVICE_PATH,
+ MSG_UART_DP,
+ {
+ (UINT8) (sizeof (UART_DEVICE_PATH)),
+ (UINT8) ((sizeof (UART_DEVICE_PATH)) >> 8)
+ }
+ },
+ 0,
+ FixedPcdGet64 (PcdUartDefaultBaudRate),
+ FixedPcdGet8 (PcdUartDefaultDataBits),
+ FixedPcdGet8 (PcdUartDefaultParity),
+ FixedPcdGet8 (PcdUartDefaultStopBits),
+ },
+ gPcAnsiTerminal,
+ gEndEntire
+};
+
//
// Predefined platform default console device path
//
@@ -169,6 +217,17 @@ PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[] = {
}
};
+PLATFORM_CONSOLE_CONNECT_ENTRY gXenPlatformConsole[] = {
+ {
+ (EFI_DEVICE_PATH_PROTOCOL *)&gXenConsoleDevicePath,
+ (CONSOLE_OUT | CONSOLE_IN | STD_ERROR)
+ },
+ {
+ NULL,
+ 0
+ }
+};
+
//
// Predefined platform connect sequence
//
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 28/31] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
On a Xen PVH guest, none of the existing serial or console interface
works, so we add a new one, based on XenConsoleSerialPortLib, and
implemeted via SerialDxe.
That a simple console implementation that can works on both PVH guest
and HVM guests, even if it rarely going to be use on HVM.
Have PlatformBootManagerLib look for the new console, when running as a
Xen guest.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
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/XenOvmf.dsc | 4 ++
OvmfPkg/XenOvmf.fdf | 1 +
OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 4 ++
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h | 1 +
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 10 +++-
OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c | 59 ++++++++++++++++++++
6 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 35af05715b..a26f611058 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -599,6 +599,10 @@ [Components]
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+ MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
+ <LibraryClasses>
+ 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/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index d614bdce1d..e078c7b405 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -298,6 +298,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 c41aaeef3f..7dd0683cd2 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -67,6 +67,10 @@ [Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile
+ 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 4948ca6518..2ab1a76f6a 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
@@ -172,6 +172,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 1a6d47732e..f186060f34 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -85,6 +85,13 @@ InstallDevicePathCallback (
VOID
);
+STATIC
+BOOLEAN
+XenDetected (
+ VOID
+ );
+
+
VOID
PlatformRegisterFvBootOption (
EFI_GUID *FileGuid,
@@ -404,7 +411,8 @@ PlatformBootManagerBeforeConsole (
//
EfiBootManagerDispatchDeferredImages ();
- PlatformInitializeConsole (gPlatformConsole);
+ PlatformInitializeConsole (
+ XenDetected() ? gXenPlatformConsole : gPlatformConsole);
PcdStatus = PcdSet16S (PcdPlatformBootTimeOut,
GetFrontPageTimeoutFromQemu ());
ASSERT_RETURN_ERROR (PcdStatus);
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
index 1250a6d351..4179370c81 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
@@ -16,6 +16,11 @@
#include "BdsPlatform.h"
#include <Guid/QemuRamfb.h>
+#define SERIAL_DXE_FILE_GUID { \
+ 0xD3987D4B, 0x971A, 0x435F, \
+ { 0x8C, 0xAF, 0x49, 0x67, 0xEB, 0x62, 0x72, 0x41 } \
+ }
+
//
// Debug Agent UART Device Path structure
//
@@ -49,6 +54,18 @@ typedef struct {
} VENDOR_RAMFB_DEVICE_PATH;
#pragma pack ()
+//
+// Xen Console Device Path structure
+//
+#pragma pack(1)
+typedef struct {
+ VENDOR_DEVICE_PATH VendorHardware;
+ UART_DEVICE_PATH Uart;
+ VENDOR_DEVICE_PATH TerminalType;
+ EFI_DEVICE_PATH_PROTOCOL End;
+} XEN_CONSOLE_DEVICE_PATH;
+#pragma pack()
+
ACPI_HID_DEVICE_PATH gPnpPs2KeyboardDeviceNode = gPnpPs2Keyboard;
ACPI_HID_DEVICE_PATH gPnp16550ComPortDeviceNode = gPnp16550ComPort;
UART_DEVICE_PATH gUartDeviceNode = gUart;
@@ -147,6 +164,37 @@ STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = {
gEndEntire
};
+STATIC XEN_CONSOLE_DEVICE_PATH gXenConsoleDevicePath = {
+ {
+ {
+ HARDWARE_DEVICE_PATH,
+ HW_VENDOR_DP,
+ {
+ (UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+ (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+ }
+ },
+ SERIAL_DXE_FILE_GUID
+ },
+ {
+ {
+ MESSAGING_DEVICE_PATH,
+ MSG_UART_DP,
+ {
+ (UINT8) (sizeof (UART_DEVICE_PATH)),
+ (UINT8) ((sizeof (UART_DEVICE_PATH)) >> 8)
+ }
+ },
+ 0,
+ FixedPcdGet64 (PcdUartDefaultBaudRate),
+ FixedPcdGet8 (PcdUartDefaultDataBits),
+ FixedPcdGet8 (PcdUartDefaultParity),
+ FixedPcdGet8 (PcdUartDefaultStopBits),
+ },
+ gPcAnsiTerminal,
+ gEndEntire
+};
+
//
// Predefined platform default console device path
//
@@ -169,6 +217,17 @@ PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[] = {
}
};
+PLATFORM_CONSOLE_CONNECT_ENTRY gXenPlatformConsole[] = {
+ {
+ (EFI_DEVICE_PATH_PROTOCOL *)&gXenConsoleDevicePath,
+ (CONSOLE_OUT | CONSOLE_IN | STD_ERROR)
+ },
+ {
+ NULL,
+ 0
+ }
+};
+
//
// Predefined platform connect sequence
//
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 28/31] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
@ 2019-04-15 14:56 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 14:56 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> On a Xen PVH guest, none of the existing serial or console interface
> works, so we add a new one, based on XenConsoleSerialPortLib, and
> implemeted via SerialDxe.
>
> That a simple console implementation that can works on both PVH guest
(1) ITYM "that *is* a simple console implementation..."
> and HVM guests, even if it rarely going to be use on HVM.
>
> Have PlatformBootManagerLib look for the new console, when running as a
> Xen guest.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> 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/XenOvmf.dsc | 4 ++
> OvmfPkg/XenOvmf.fdf | 1 +
> OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 4 ++
> OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h | 1 +
> OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 10 +++-
> OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c | 59 ++++++++++++++++++++
> 6 files changed, 78 insertions(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 35af05715b..a26f611058 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -599,6 +599,10 @@ [Components]
> OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> OvmfPkg/XenBusDxe/XenBusDxe.inf
> OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> + MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
> + <LibraryClasses>
> + 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/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index d614bdce1d..e078c7b405 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -298,6 +298,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
(2) Do you really need all three of:
- MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
- IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
- MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
for supporting both HVM and PVH? If possible I'd suggest just the last
one, plus a general resolution of SerialPortLib to
XenConsoleSerialPortLib.
Or would that force HVM users to change their domU configs?
(Anyway I don't feel strongly about this question, with regard to the
OvmfXen platform.)
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index c41aaeef3f..7dd0683cd2 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -67,6 +67,10 @@ [Pcd]
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
> gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
> gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile
> + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
> + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
> + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity ## CONSUMES
> + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>
> [Pcd.IA32, Pcd.X64]
> gEfiMdePkgTokenSpaceGuid.PcdFSBClock
(3) If possible, please keep PCDs from the space token space GUID
(gEfiMdePkgTokenSpaceGuid) clustered near each other.
("Fully sorted" is optimal, but in many cases the PCD lists we have
already aren't sorted, and then I prefer sorting to be a separate patch
-- but that's really not necessary here.)
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> index 4948ca6518..2ab1a76f6a 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> @@ -172,6 +172,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 1a6d47732e..f186060f34 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -85,6 +85,13 @@ InstallDevicePathCallback (
> VOID
> );
>
> +STATIC
> +BOOLEAN
> +XenDetected (
> + VOID
> + );
> +
> +
> VOID
> PlatformRegisterFvBootOption (
> EFI_GUID *FileGuid,
(4) OK, this has convinced me:
(4a) please rebase PlatformBootManagerLib to XenPlatformLib first,
removing the open-coded XenDetected() function -- this should be a
separate patch
(4b) once you do that, my concern for "v2 25/31" can also be addressed
easily -- you can simply repeat the XenPvhDetected() restriction
from XenPlatformPei() in PlatformBootManagerLib too.
> @@ -404,7 +411,8 @@ PlatformBootManagerBeforeConsole (
> //
> EfiBootManagerDispatchDeferredImages ();
>
> - PlatformInitializeConsole (gPlatformConsole);
> + PlatformInitializeConsole (
> + XenDetected() ? gXenPlatformConsole : gPlatformConsole);
> PcdStatus = PcdSet16S (PcdPlatformBootTimeOut,
> GetFrontPageTimeoutFromQemu ());
> ASSERT_RETURN_ERROR (PcdStatus);
Aha, so my question under (2) does make sense! If you are switching to
the Xen console just based on XenDetected(), that includes HVM domUs
too, and so you should be able to drop both PciSioSerialDxe and
IsaSerialDxe from the OvmfXen platform.
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> index 1250a6d351..4179370c81 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> @@ -16,6 +16,11 @@
> #include "BdsPlatform.h"
> #include <Guid/QemuRamfb.h>
>
> +#define SERIAL_DXE_FILE_GUID { \
> + 0xD3987D4B, 0x971A, 0x435F, \
> + { 0x8C, 0xAF, 0x49, 0x67, 0xEB, 0x62, 0x72, 0x41 } \
> + }
> +
> //
> // Debug Agent UART Device Path structure
> //
Ah cool, now we have *four* separate #define's for this GUID :(
- ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
- ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
- CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformConsole.c
- OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
This is obviously an omission in MdeModulePkg at this point.
(5) Please write a separate patch for "MdeModulePkg.dec" and
"MdeModulePkg/Include/Guid/" -- given that the FILE_GUID of
"MdeModulePkg/Universal/SerialDxe" has to be placed into device paths by
multiple platforms, and SerialDxe calls itself "Universal", MdeModulePkg
itself should offer the GUID ready for consumption.
Then all three of the above (preexistent) consumers should be updated to
take the GUID from that location.
I suggest discussing this with the MdeModulePkg maintainers, and if they
agree, I recommend implementing this GUID-extraction in an independent
series, before spinning v3 of XenPVH. (In v3, the GUID should be
consumed like described above.)
... Yes, it's quite arbitrary that I'm asking for the extraction of the
GUID at this point, and not earlier. Sorry about that.
> @@ -49,6 +54,18 @@ typedef struct {
> } VENDOR_RAMFB_DEVICE_PATH;
> #pragma pack ()
>
> +//
> +// Xen Console Device Path structure
> +//
> +#pragma pack(1)
> +typedef struct {
> + VENDOR_DEVICE_PATH VendorHardware;
> + UART_DEVICE_PATH Uart;
> + VENDOR_DEVICE_PATH TerminalType;
> + EFI_DEVICE_PATH_PROTOCOL End;
> +} XEN_CONSOLE_DEVICE_PATH;
> +#pragma pack()
> +
> ACPI_HID_DEVICE_PATH gPnpPs2KeyboardDeviceNode = gPnpPs2Keyboard;
> ACPI_HID_DEVICE_PATH gPnp16550ComPortDeviceNode = gPnp16550ComPort;
> UART_DEVICE_PATH gUartDeviceNode = gUart;
(6) Can you please insert a space between "pack" and "(1)"?
> @@ -147,6 +164,37 @@ STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = {
> gEndEntire
> };
>
> +STATIC XEN_CONSOLE_DEVICE_PATH gXenConsoleDevicePath = {
> + {
> + {
> + HARDWARE_DEVICE_PATH,
> + HW_VENDOR_DP,
> + {
> + (UINT8) (sizeof (VENDOR_DEVICE_PATH)),
> + (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
> + }
> + },
> + SERIAL_DXE_FILE_GUID
> + },
> + {
> + {
> + MESSAGING_DEVICE_PATH,
> + MSG_UART_DP,
> + {
> + (UINT8) (sizeof (UART_DEVICE_PATH)),
> + (UINT8) ((sizeof (UART_DEVICE_PATH)) >> 8)
> + }
> + },
> + 0,
> + FixedPcdGet64 (PcdUartDefaultBaudRate),
> + FixedPcdGet8 (PcdUartDefaultDataBits),
> + FixedPcdGet8 (PcdUartDefaultParity),
> + FixedPcdGet8 (PcdUartDefaultStopBits),
> + },
> + gPcAnsiTerminal,
> + gEndEntire
> +};
> +
> //
> // Predefined platform default console device path
> //
> @@ -169,6 +217,17 @@ PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[] = {
> }
> };
>
> +PLATFORM_CONSOLE_CONNECT_ENTRY gXenPlatformConsole[] = {
> + {
> + (EFI_DEVICE_PATH_PROTOCOL *)&gXenConsoleDevicePath,
> + (CONSOLE_OUT | CONSOLE_IN | STD_ERROR)
> + },
> + {
> + NULL,
> + 0
> + }
> +};
> +
> //
> // Predefined platform connect sequence
> //
>
The rest looks OK to me, although at this point my brain is mush and you
could sell me anything. Stopping with the review for today.
Thanks,
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 28/31] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
@ 2019-04-15 14:56 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-15 14:56 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> On a Xen PVH guest, none of the existing serial or console interface
> works, so we add a new one, based on XenConsoleSerialPortLib, and
> implemeted via SerialDxe.
>
> That a simple console implementation that can works on both PVH guest
(1) ITYM "that *is* a simple console implementation..."
> and HVM guests, even if it rarely going to be use on HVM.
>
> Have PlatformBootManagerLib look for the new console, when running as a
> Xen guest.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> 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/XenOvmf.dsc | 4 ++
> OvmfPkg/XenOvmf.fdf | 1 +
> OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 4 ++
> OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h | 1 +
> OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 10 +++-
> OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c | 59 ++++++++++++++++++++
> 6 files changed, 78 insertions(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 35af05715b..a26f611058 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -599,6 +599,10 @@ [Components]
> OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> OvmfPkg/XenBusDxe/XenBusDxe.inf
> OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> + MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
> + <LibraryClasses>
> + 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/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index d614bdce1d..e078c7b405 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -298,6 +298,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
(2) Do you really need all three of:
- MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
- IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
- MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
for supporting both HVM and PVH? If possible I'd suggest just the last
one, plus a general resolution of SerialPortLib to
XenConsoleSerialPortLib.
Or would that force HVM users to change their domU configs?
(Anyway I don't feel strongly about this question, with regard to the
OvmfXen platform.)
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index c41aaeef3f..7dd0683cd2 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -67,6 +67,10 @@ [Pcd]
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
> gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
> gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile
> + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
> + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
> + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity ## CONSUMES
> + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>
> [Pcd.IA32, Pcd.X64]
> gEfiMdePkgTokenSpaceGuid.PcdFSBClock
(3) If possible, please keep PCDs from the space token space GUID
(gEfiMdePkgTokenSpaceGuid) clustered near each other.
("Fully sorted" is optimal, but in many cases the PCD lists we have
already aren't sorted, and then I prefer sorting to be a separate patch
-- but that's really not necessary here.)
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> index 4948ca6518..2ab1a76f6a 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> @@ -172,6 +172,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 1a6d47732e..f186060f34 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -85,6 +85,13 @@ InstallDevicePathCallback (
> VOID
> );
>
> +STATIC
> +BOOLEAN
> +XenDetected (
> + VOID
> + );
> +
> +
> VOID
> PlatformRegisterFvBootOption (
> EFI_GUID *FileGuid,
(4) OK, this has convinced me:
(4a) please rebase PlatformBootManagerLib to XenPlatformLib first,
removing the open-coded XenDetected() function -- this should be a
separate patch
(4b) once you do that, my concern for "v2 25/31" can also be addressed
easily -- you can simply repeat the XenPvhDetected() restriction
from XenPlatformPei() in PlatformBootManagerLib too.
> @@ -404,7 +411,8 @@ PlatformBootManagerBeforeConsole (
> //
> EfiBootManagerDispatchDeferredImages ();
>
> - PlatformInitializeConsole (gPlatformConsole);
> + PlatformInitializeConsole (
> + XenDetected() ? gXenPlatformConsole : gPlatformConsole);
> PcdStatus = PcdSet16S (PcdPlatformBootTimeOut,
> GetFrontPageTimeoutFromQemu ());
> ASSERT_RETURN_ERROR (PcdStatus);
Aha, so my question under (2) does make sense! If you are switching to
the Xen console just based on XenDetected(), that includes HVM domUs
too, and so you should be able to drop both PciSioSerialDxe and
IsaSerialDxe from the OvmfXen platform.
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> index 1250a6d351..4179370c81 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> @@ -16,6 +16,11 @@
> #include "BdsPlatform.h"
> #include <Guid/QemuRamfb.h>
>
> +#define SERIAL_DXE_FILE_GUID { \
> + 0xD3987D4B, 0x971A, 0x435F, \
> + { 0x8C, 0xAF, 0x49, 0x67, 0xEB, 0x62, 0x72, 0x41 } \
> + }
> +
> //
> // Debug Agent UART Device Path structure
> //
Ah cool, now we have *four* separate #define's for this GUID :(
- ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
- ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
- CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformConsole.c
- OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
This is obviously an omission in MdeModulePkg at this point.
(5) Please write a separate patch for "MdeModulePkg.dec" and
"MdeModulePkg/Include/Guid/" -- given that the FILE_GUID of
"MdeModulePkg/Universal/SerialDxe" has to be placed into device paths by
multiple platforms, and SerialDxe calls itself "Universal", MdeModulePkg
itself should offer the GUID ready for consumption.
Then all three of the above (preexistent) consumers should be updated to
take the GUID from that location.
I suggest discussing this with the MdeModulePkg maintainers, and if they
agree, I recommend implementing this GUID-extraction in an independent
series, before spinning v3 of XenPVH. (In v3, the GUID should be
consumed like described above.)
... Yes, it's quite arbitrary that I'm asking for the extraction of the
GUID at this point, and not earlier. Sorry about that.
> @@ -49,6 +54,18 @@ typedef struct {
> } VENDOR_RAMFB_DEVICE_PATH;
> #pragma pack ()
>
> +//
> +// Xen Console Device Path structure
> +//
> +#pragma pack(1)
> +typedef struct {
> + VENDOR_DEVICE_PATH VendorHardware;
> + UART_DEVICE_PATH Uart;
> + VENDOR_DEVICE_PATH TerminalType;
> + EFI_DEVICE_PATH_PROTOCOL End;
> +} XEN_CONSOLE_DEVICE_PATH;
> +#pragma pack()
> +
> ACPI_HID_DEVICE_PATH gPnpPs2KeyboardDeviceNode = gPnpPs2Keyboard;
> ACPI_HID_DEVICE_PATH gPnp16550ComPortDeviceNode = gPnp16550ComPort;
> UART_DEVICE_PATH gUartDeviceNode = gUart;
(6) Can you please insert a space between "pack" and "(1)"?
> @@ -147,6 +164,37 @@ STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = {
> gEndEntire
> };
>
> +STATIC XEN_CONSOLE_DEVICE_PATH gXenConsoleDevicePath = {
> + {
> + {
> + HARDWARE_DEVICE_PATH,
> + HW_VENDOR_DP,
> + {
> + (UINT8) (sizeof (VENDOR_DEVICE_PATH)),
> + (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
> + }
> + },
> + SERIAL_DXE_FILE_GUID
> + },
> + {
> + {
> + MESSAGING_DEVICE_PATH,
> + MSG_UART_DP,
> + {
> + (UINT8) (sizeof (UART_DEVICE_PATH)),
> + (UINT8) ((sizeof (UART_DEVICE_PATH)) >> 8)
> + }
> + },
> + 0,
> + FixedPcdGet64 (PcdUartDefaultBaudRate),
> + FixedPcdGet8 (PcdUartDefaultDataBits),
> + FixedPcdGet8 (PcdUartDefaultParity),
> + FixedPcdGet8 (PcdUartDefaultStopBits),
> + },
> + gPcAnsiTerminal,
> + gEndEntire
> +};
> +
> //
> // Predefined platform default console device path
> //
> @@ -169,6 +217,17 @@ PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[] = {
> }
> };
>
> +PLATFORM_CONSOLE_CONNECT_ENTRY gXenPlatformConsole[] = {
> + {
> + (EFI_DEVICE_PATH_PROTOCOL *)&gXenConsoleDevicePath,
> + (CONSOLE_OUT | CONSOLE_IN | STD_ERROR)
> + },
> + {
> + NULL,
> + 0
> + }
> +};
> +
> //
> // Predefined platform connect sequence
> //
>
The rest looks OK to me, although at this point my brain is mush and you
could sell me anything. Stopping with the review for today.
Thanks,
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 29/31] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This "device" use XenIoMmioLib to reserve some space to be use by the
Grant Tables.
The call is only done if it is necessary, we simply detect if the guest
is probably PVH, as in this case there is currently no PCI bus, and no
PCI Xen platform device which would start the XenIoPciDxe and allocate
the space for the Grant Tables.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
v2:
- do allocation in EntryPoint like the other user of XenIoMmioLib.
- allocate memory instead of hardcoded addr.
- cleanup, add copyright
- detect if we are running in PVH mode
OvmfPkg/XenOvmf.dsc | 2 ++
OvmfPkg/XenOvmf.fdf | 1 +
OvmfPkg/{XenIoPciDxe/XenIoPciDxe.inf => XenIoPvhDxe/XenIoPvhDxe.inf} | 26 +++++---------
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 38 ++++++++++++++++++++
4 files changed, 49 insertions(+), 18 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index a26f611058..72d6ea8b29 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -199,6 +199,7 @@ [LibraryClasses]
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
+ XenIoMmioLib|OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
@@ -596,6 +597,7 @@ [Components]
NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
!endif
}
+ OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index e078c7b405..9aa998f15f 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -295,6 +295,7 @@ [FV.DXEFV]
INF MdeModulePkg/Universal/Metronome/Metronome.inf
INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
similarity index 56%
copy from OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
copy to OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
index b32075a381..985b6d54b7 100644
--- a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
+++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
@@ -1,7 +1,7 @@
## @file
-# Driver for the virtual Xen PCI device
+# Driver for the XenIo protocol
#
-# Copyright (C) 2015, Linaro Ltd.
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -15,31 +15,21 @@
[Defines]
INF_VERSION = 0x00010005
- BASE_NAME = XenIoPciDxe
- FILE_GUID = cf569f50-de44-4f54-b4d7-f4ae25cda599
+ BASE_NAME = XenIoPvhDxe
+ FILE_GUID = 7a567cc4-0e75-4d7a-a305-c3db109b53ad
MODULE_TYPE = UEFI_DRIVER
VERSION_STRING = 1.0
- ENTRY_POINT = XenIoPciDeviceEntryPoint
+ ENTRY_POINT = InitializeXenIoPvhDxe
[Packages]
MdePkg/MdePkg.dec
OvmfPkg/OvmfPkg.dec
[Sources]
- XenIoPciDxe.c
+ XenIoPvhDxe.c
[LibraryClasses]
UefiDriverEntryPoint
- UefiBootServicesTableLib
MemoryAllocationLib
- BaseMemoryLib
- BaseLib
- UefiLib
- DebugLib
-
-[Protocols]
- gEfiDriverBindingProtocolGuid
- gEfiPciIoProtocolGuid
- gEfiComponentName2ProtocolGuid
- gEfiComponentNameProtocolGuid
- gXenIoProtocolGuid
+ XenIoMmioLib
+ XenPlatformLib
diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
new file mode 100644
index 0000000000..f2113b768c
--- /dev/null
+++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
@@ -0,0 +1,38 @@
+/** @file
+
+ Driver for the XenIo protocol
+
+ This driver simply allocate space for the grant tables.
+
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ This program and the accompanying materials are licensed and made available
+ under the terms and conditions of the BSD License which accompanies this
+ distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+ WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include <Library/MemoryAllocationLib.h>
+#include <Library/XenIoMmioLib.h>
+#include <Library/XenPlatformLib.h>
+
+EFI_STATUS
+EFIAPI
+InitializeXenIoPvhDxe (
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ if (XenPvhDetected ()) {
+ EFI_HANDLE Handle;
+
+ Handle = NULL;
+ return XenIoMmioInstall (&Handle, (UINTN) AllocateReservedPages (4));
+ }
+
+ return EFI_SUCCESS;
+}
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 29/31] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This "device" use XenIoMmioLib to reserve some space to be use by the
Grant Tables.
The call is only done if it is necessary, we simply detect if the guest
is probably PVH, as in this case there is currently no PCI bus, and no
PCI Xen platform device which would start the XenIoPciDxe and allocate
the space for the Grant Tables.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
v2:
- do allocation in EntryPoint like the other user of XenIoMmioLib.
- allocate memory instead of hardcoded addr.
- cleanup, add copyright
- detect if we are running in PVH mode
OvmfPkg/XenOvmf.dsc | 2 ++
OvmfPkg/XenOvmf.fdf | 1 +
OvmfPkg/{XenIoPciDxe/XenIoPciDxe.inf => XenIoPvhDxe/XenIoPvhDxe.inf} | 26 +++++---------
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 38 ++++++++++++++++++++
4 files changed, 49 insertions(+), 18 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index a26f611058..72d6ea8b29 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -199,6 +199,7 @@ [LibraryClasses]
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
+ XenIoMmioLib|OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
@@ -596,6 +597,7 @@ [Components]
NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
!endif
}
+ OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index e078c7b405..9aa998f15f 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -295,6 +295,7 @@ [FV.DXEFV]
INF MdeModulePkg/Universal/Metronome/Metronome.inf
INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
similarity index 56%
copy from OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
copy to OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
index b32075a381..985b6d54b7 100644
--- a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
+++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
@@ -1,7 +1,7 @@
## @file
-# Driver for the virtual Xen PCI device
+# Driver for the XenIo protocol
#
-# Copyright (C) 2015, Linaro Ltd.
+# Copyright (c) 2019, Citrix Systems, Inc.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -15,31 +15,21 @@
[Defines]
INF_VERSION = 0x00010005
- BASE_NAME = XenIoPciDxe
- FILE_GUID = cf569f50-de44-4f54-b4d7-f4ae25cda599
+ BASE_NAME = XenIoPvhDxe
+ FILE_GUID = 7a567cc4-0e75-4d7a-a305-c3db109b53ad
MODULE_TYPE = UEFI_DRIVER
VERSION_STRING = 1.0
- ENTRY_POINT = XenIoPciDeviceEntryPoint
+ ENTRY_POINT = InitializeXenIoPvhDxe
[Packages]
MdePkg/MdePkg.dec
OvmfPkg/OvmfPkg.dec
[Sources]
- XenIoPciDxe.c
+ XenIoPvhDxe.c
[LibraryClasses]
UefiDriverEntryPoint
- UefiBootServicesTableLib
MemoryAllocationLib
- BaseMemoryLib
- BaseLib
- UefiLib
- DebugLib
-
-[Protocols]
- gEfiDriverBindingProtocolGuid
- gEfiPciIoProtocolGuid
- gEfiComponentName2ProtocolGuid
- gEfiComponentNameProtocolGuid
- gXenIoProtocolGuid
+ XenIoMmioLib
+ XenPlatformLib
diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
new file mode 100644
index 0000000000..f2113b768c
--- /dev/null
+++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
@@ -0,0 +1,38 @@
+/** @file
+
+ Driver for the XenIo protocol
+
+ This driver simply allocate space for the grant tables.
+
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ This program and the accompanying materials are licensed and made available
+ under the terms and conditions of the BSD License which accompanies this
+ distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+ WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include <Library/MemoryAllocationLib.h>
+#include <Library/XenIoMmioLib.h>
+#include <Library/XenPlatformLib.h>
+
+EFI_STATUS
+EFIAPI
+InitializeXenIoPvhDxe (
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ if (XenPvhDetected ()) {
+ EFI_HANDLE Handle;
+
+ Handle = NULL;
+ return XenIoMmioInstall (&Handle, (UINTN) AllocateReservedPages (4));
+ }
+
+ return EFI_SUCCESS;
+}
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 29/31] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
@ 2019-04-16 8:49 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-16 8:49 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This "device" use XenIoMmioLib to reserve some space to be use by the
> Grant Tables.
(1) can we replace "this device" with "XenIoPvhDxe"?
>
> The call is only done if it is necessary, we simply detect if the guest
> is probably PVH, as in this case there is currently no PCI bus, and no
(2) why "probably"? I've been under the impression that XenPvhDetected()
is decisive.
> PCI Xen platform device which would start the XenIoPciDxe and allocate
> the space for the Grant Tables.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> v2:
> - do allocation in EntryPoint like the other user of XenIoMmioLib.
> - allocate memory instead of hardcoded addr.
> - cleanup, add copyright
> - detect if we are running in PVH mode
>
> OvmfPkg/XenOvmf.dsc | 2 ++
> OvmfPkg/XenOvmf.fdf | 1 +
> OvmfPkg/{XenIoPciDxe/XenIoPciDxe.inf => XenIoPvhDxe/XenIoPvhDxe.inf} | 26 +++++---------
> OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 38 ++++++++++++++++++++
> 4 files changed, 49 insertions(+), 18 deletions(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index a26f611058..72d6ea8b29 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -199,6 +199,7 @@ [LibraryClasses]
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
> + XenIoMmioLib|OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
>
> Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
>
> @@ -596,6 +597,7 @@ [Components]
> NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> !endif
> }
> + OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> OvmfPkg/XenBusDxe/XenBusDxe.inf
> OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index e078c7b405..9aa998f15f 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -295,6 +295,7 @@ [FV.DXEFV]
> INF MdeModulePkg/Universal/Metronome/Metronome.inf
> INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
>
> +INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> INF OvmfPkg/XenBusDxe/XenBusDxe.inf
> INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
So you keep both drivers in OvmfXen. Is there any chance that both
drivers will launch successfully and the protocol database ends up with
two instances of gXenIoProtocolGuid?
... If the PCI device PCI_VENDOR_ID_XEN/PCI_DEVICE_ID_XEN_PLATFORM is
exclusive to HVM, then I guess the mutual exclusion is guaranteed.
> diff --git a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> similarity index 56%
> copy from OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> copy to OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
(this is a false positive of "--find-copies-harder", OK)
> index b32075a381..985b6d54b7 100644
> --- a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> +++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> @@ -1,7 +1,7 @@
> ## @file
> -# Driver for the virtual Xen PCI device
> +# Driver for the XenIo protocol
> #
> -# Copyright (C) 2015, Linaro Ltd.
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> @@ -15,31 +15,21 @@
>
> [Defines]
> INF_VERSION = 0x00010005
> - BASE_NAME = XenIoPciDxe
> - FILE_GUID = cf569f50-de44-4f54-b4d7-f4ae25cda599
> + BASE_NAME = XenIoPvhDxe
> + FILE_GUID = 7a567cc4-0e75-4d7a-a305-c3db109b53ad
> MODULE_TYPE = UEFI_DRIVER
(3) Please "downgrade" this to DXE_DRIVER. This driver doesn't follow
the UEFI driver model (which is fine), and there is no reason to suggest
it is more than a DXE (i.e., platform) driver.
For that, you'll have to introduce a [Depex] section, but I think it can
be just TRUE -- I don't think you need any particular protocols
(architectural or not).
> VERSION_STRING = 1.0
> - ENTRY_POINT = XenIoPciDeviceEntryPoint
> + ENTRY_POINT = InitializeXenIoPvhDxe
>
> [Packages]
> MdePkg/MdePkg.dec
> OvmfPkg/OvmfPkg.dec
>
> [Sources]
> - XenIoPciDxe.c
> + XenIoPvhDxe.c
>
> [LibraryClasses]
> UefiDriverEntryPoint
> - UefiBootServicesTableLib
> MemoryAllocationLib
> - BaseMemoryLib
> - BaseLib
> - UefiLib
> - DebugLib
> -
> -[Protocols]
> - gEfiDriverBindingProtocolGuid
> - gEfiPciIoProtocolGuid
> - gEfiComponentName2ProtocolGuid
> - gEfiComponentNameProtocolGuid
> - gXenIoProtocolGuid
> + XenIoMmioLib
> + XenPlatformLib
> diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> new file mode 100644
> index 0000000000..f2113b768c
> --- /dev/null
> +++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> @@ -0,0 +1,38 @@
> +/** @file
> +
> + Driver for the XenIo protocol
> +
> + This driver simply allocate space for the grant tables.
> +
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> + This program and the accompanying materials are licensed and made available
> + under the terms and conditions of the BSD License which accompanies this
> + distribution. The full text of the license may be found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
> + WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
(4) please update the license block in both new files to the SPDX ID format.
> +
> +#include <Library/MemoryAllocationLib.h>
> +#include <Library/XenIoMmioLib.h>
> +#include <Library/XenPlatformLib.h>
> +
> +EFI_STATUS
> +EFIAPI
> +InitializeXenIoPvhDxe (
> + IN EFI_HANDLE ImageHandle,
> + IN EFI_SYSTEM_TABLE *SystemTable
> + )
> +{
> + if (XenPvhDetected ()) {
> + EFI_HANDLE Handle;
> +
> + Handle = NULL;
> + return XenIoMmioInstall (&Handle, (UINTN) AllocateReservedPages (4));
> + }
> +
> + return EFI_SUCCESS;
> +}
>
(5) Please check the return value of AllocateReservedPages(), and exit
the driver with a failure (EFI_OUT_OF_RESOURCES) if that fails.
(6) Do we really need to reserve the RAM away from the OS forever? (It's
fine if we do, I'm just curious.)
Because, if the OS sets up its own grant tables anyway, then we could
allocate EfiBootServicesData type memory here -- and perhaps add an
ExitBootServices() callback to disconnect from Xen (i.e. make sure that
the firmware-allocated grant tables are no longer used).
... Not sure if this makes sense (I don't remember if we discussed it
under v1).
(7) Please check the return value of XenIoMmioInstall(), and if it
fails, release the allocated memory first, and then propagate the error
as the driver's exit status.
(8) If XenPvhDetected() returns FALSE, I recommend exiting the driver
with EFI_UNSUPPORTED.
(There's an argument to be made for exiting the driver with an error
code even if we successfully call XenIoMmioInstall(), as it's not really
necessary to keep the driver image in memory after that. This kind of
driver is called the "initializing driver". However, I do find that
non-intuitive (in particular the DXE Core will report the startup
failure, and it is confusing when analyzing logs); plus if you do decide
to add the EBS() callback, then the driver will have to stay resident on
success. Either way returning EFI_SUCCESS on success is OK.)
Thanks,
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 29/31] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
@ 2019-04-16 8:49 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-16 8:49 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> This "device" use XenIoMmioLib to reserve some space to be use by the
> Grant Tables.
(1) can we replace "this device" with "XenIoPvhDxe"?
>
> The call is only done if it is necessary, we simply detect if the guest
> is probably PVH, as in this case there is currently no PCI bus, and no
(2) why "probably"? I've been under the impression that XenPvhDetected()
is decisive.
> PCI Xen platform device which would start the XenIoPciDxe and allocate
> the space for the Grant Tables.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> v2:
> - do allocation in EntryPoint like the other user of XenIoMmioLib.
> - allocate memory instead of hardcoded addr.
> - cleanup, add copyright
> - detect if we are running in PVH mode
>
> OvmfPkg/XenOvmf.dsc | 2 ++
> OvmfPkg/XenOvmf.fdf | 1 +
> OvmfPkg/{XenIoPciDxe/XenIoPciDxe.inf => XenIoPvhDxe/XenIoPvhDxe.inf} | 26 +++++---------
> OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 38 ++++++++++++++++++++
> 4 files changed, 49 insertions(+), 18 deletions(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index a26f611058..72d6ea8b29 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -199,6 +199,7 @@ [LibraryClasses]
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
> + XenIoMmioLib|OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
>
> Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
>
> @@ -596,6 +597,7 @@ [Components]
> NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> !endif
> }
> + OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> OvmfPkg/XenBusDxe/XenBusDxe.inf
> OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index e078c7b405..9aa998f15f 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -295,6 +295,7 @@ [FV.DXEFV]
> INF MdeModulePkg/Universal/Metronome/Metronome.inf
> INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
>
> +INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> INF OvmfPkg/XenBusDxe/XenBusDxe.inf
> INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
So you keep both drivers in OvmfXen. Is there any chance that both
drivers will launch successfully and the protocol database ends up with
two instances of gXenIoProtocolGuid?
... If the PCI device PCI_VENDOR_ID_XEN/PCI_DEVICE_ID_XEN_PLATFORM is
exclusive to HVM, then I guess the mutual exclusion is guaranteed.
> diff --git a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> similarity index 56%
> copy from OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> copy to OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
(this is a false positive of "--find-copies-harder", OK)
> index b32075a381..985b6d54b7 100644
> --- a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> +++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> @@ -1,7 +1,7 @@
> ## @file
> -# Driver for the virtual Xen PCI device
> +# Driver for the XenIo protocol
> #
> -# Copyright (C) 2015, Linaro Ltd.
> +# Copyright (c) 2019, Citrix Systems, Inc.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD License
> @@ -15,31 +15,21 @@
>
> [Defines]
> INF_VERSION = 0x00010005
> - BASE_NAME = XenIoPciDxe
> - FILE_GUID = cf569f50-de44-4f54-b4d7-f4ae25cda599
> + BASE_NAME = XenIoPvhDxe
> + FILE_GUID = 7a567cc4-0e75-4d7a-a305-c3db109b53ad
> MODULE_TYPE = UEFI_DRIVER
(3) Please "downgrade" this to DXE_DRIVER. This driver doesn't follow
the UEFI driver model (which is fine), and there is no reason to suggest
it is more than a DXE (i.e., platform) driver.
For that, you'll have to introduce a [Depex] section, but I think it can
be just TRUE -- I don't think you need any particular protocols
(architectural or not).
> VERSION_STRING = 1.0
> - ENTRY_POINT = XenIoPciDeviceEntryPoint
> + ENTRY_POINT = InitializeXenIoPvhDxe
>
> [Packages]
> MdePkg/MdePkg.dec
> OvmfPkg/OvmfPkg.dec
>
> [Sources]
> - XenIoPciDxe.c
> + XenIoPvhDxe.c
>
> [LibraryClasses]
> UefiDriverEntryPoint
> - UefiBootServicesTableLib
> MemoryAllocationLib
> - BaseMemoryLib
> - BaseLib
> - UefiLib
> - DebugLib
> -
> -[Protocols]
> - gEfiDriverBindingProtocolGuid
> - gEfiPciIoProtocolGuid
> - gEfiComponentName2ProtocolGuid
> - gEfiComponentNameProtocolGuid
> - gXenIoProtocolGuid
> + XenIoMmioLib
> + XenPlatformLib
> diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> new file mode 100644
> index 0000000000..f2113b768c
> --- /dev/null
> +++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> @@ -0,0 +1,38 @@
> +/** @file
> +
> + Driver for the XenIo protocol
> +
> + This driver simply allocate space for the grant tables.
> +
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> + This program and the accompanying materials are licensed and made available
> + under the terms and conditions of the BSD License which accompanies this
> + distribution. The full text of the license may be found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
> + WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
(4) please update the license block in both new files to the SPDX ID format.
> +
> +#include <Library/MemoryAllocationLib.h>
> +#include <Library/XenIoMmioLib.h>
> +#include <Library/XenPlatformLib.h>
> +
> +EFI_STATUS
> +EFIAPI
> +InitializeXenIoPvhDxe (
> + IN EFI_HANDLE ImageHandle,
> + IN EFI_SYSTEM_TABLE *SystemTable
> + )
> +{
> + if (XenPvhDetected ()) {
> + EFI_HANDLE Handle;
> +
> + Handle = NULL;
> + return XenIoMmioInstall (&Handle, (UINTN) AllocateReservedPages (4));
> + }
> +
> + return EFI_SUCCESS;
> +}
>
(5) Please check the return value of AllocateReservedPages(), and exit
the driver with a failure (EFI_OUT_OF_RESOURCES) if that fails.
(6) Do we really need to reserve the RAM away from the OS forever? (It's
fine if we do, I'm just curious.)
Because, if the OS sets up its own grant tables anyway, then we could
allocate EfiBootServicesData type memory here -- and perhaps add an
ExitBootServices() callback to disconnect from Xen (i.e. make sure that
the firmware-allocated grant tables are no longer used).
... Not sure if this makes sense (I don't remember if we discussed it
under v1).
(7) Please check the return value of XenIoMmioInstall(), and if it
fails, release the allocated memory first, and then propagate the error
as the driver's exit status.
(8) If XenPvhDetected() returns FALSE, I recommend exiting the driver
with EFI_UNSUPPORTED.
(There's an argument to be made for exiting the driver with an error
code even if we successfully call XenIoMmioInstall(), as it's not really
necessary to keep the driver image in memory after that. This kind of
driver is called the "initializing driver". However, I do find that
non-intuitive (in particular the DXE Core will report the startup
failure, and it is confusing when analyzing logs); plus if you do decide
to add the EBS() callback, then the driver will have to stay resident on
success. Either way returning EFI_SUCCESS on success is OK.)
Thanks,
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 30/31] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
So it can be used from the OvmfPkg by the following patch,
"OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg"
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
ArmVirtPkg/ArmVirtXen.dsc | 2 +-
{ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf | 0
{ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c | 0
3 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index a3688ae2cb..d5d8d79561 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -33,7 +33,7 @@ [Defines]
[LibraryClasses]
SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
- RealTimeClockLib|ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
+ RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
ArmGenericTimerCounterLib|ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
similarity index 100%
rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
similarity index 100%
rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 30/31] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
So it can be used from the OvmfPkg by the following patch,
"OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg"
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
ArmVirtPkg/ArmVirtXen.dsc | 2 +-
{ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf | 0
{ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c | 0
3 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index a3688ae2cb..d5d8d79561 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -33,7 +33,7 @@ [Defines]
[LibraryClasses]
SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
- RealTimeClockLib|ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
+ RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
ArmGenericTimerCounterLib|ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
similarity index 100%
rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
similarity index 100%
rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 30/31] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
@ 2019-04-16 8:53 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-16 8:53 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> So it can be used from the OvmfPkg by the following patch,
> "OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg"
(1) Please make the commit message self-contained.
with that,
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> ArmVirtPkg/ArmVirtXen.dsc | 2 +-
> {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf | 0
> {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c | 0
> 3 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index a3688ae2cb..d5d8d79561 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -33,7 +33,7 @@ [Defines]
>
> [LibraryClasses]
> SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
> - RealTimeClockLib|ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> + RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>
> ArmGenericTimerCounterLib|ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
> diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> similarity index 100%
> rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
> similarity index 100%
> rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
> rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 30/31] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
@ 2019-04-16 8:53 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-16 8:53 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> So it can be used from the OvmfPkg by the following patch,
> "OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg"
(1) Please make the commit message self-contained.
with that,
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> ArmVirtPkg/ArmVirtXen.dsc | 2 +-
> {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf | 0
> {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c | 0
> 3 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index a3688ae2cb..d5d8d79561 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -33,7 +33,7 @@ [Defines]
>
> [LibraryClasses]
> SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
> - RealTimeClockLib|ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> + RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>
> ArmGenericTimerCounterLib|ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
> diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> similarity index 100%
> rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
> similarity index 100%
> rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
> rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread
* [PATCH v2 31/31] OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
A Xen PVH guest doesn't have a RTC that OVMF would expect, so
PcatRealTimeClockRuntimeDxe fails to initialize and prevent the firmware
from finish to boot. To prevent that, we will use the
XenRealTimeClockLib from ArmVirtPkg which simply always return the same
time. This will work on both Xen PVH and HVM guests.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenOvmf.dsc | 5 ++++-
OvmfPkg/XenOvmf.fdf | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 72d6ea8b29..14ef9ea9f2 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -577,7 +577,10 @@ [Components]
}
MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
MdeModulePkg/Universal/Metronome/Metronome.inf
- PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+ EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf {
+ <LibraryClasses>
+ RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
+ }
MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
<LibraryClasses>
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 9aa998f15f..1b62da2ec5 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -293,7 +293,7 @@ [FV.DXEFV]
INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
INF MdeModulePkg/Universal/Metronome/Metronome.inf
-INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* [Xen-devel] [PATCH v2 31/31] OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg
@ 2019-04-09 11:08 ` Anthony PERARD
0 siblings, 0 replies; 168+ messages in thread
From: Anthony PERARD @ 2019-04-09 11:08 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
A Xen PVH guest doesn't have a RTC that OVMF would expect, so
PcatRealTimeClockRuntimeDxe fails to initialize and prevent the firmware
from finish to boot. To prevent that, we will use the
XenRealTimeClockLib from ArmVirtPkg which simply always return the same
time. This will work on both Xen PVH and HVM guests.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/XenOvmf.dsc | 5 ++++-
OvmfPkg/XenOvmf.fdf | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 72d6ea8b29..14ef9ea9f2 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -577,7 +577,10 @@ [Components]
}
MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
MdeModulePkg/Universal/Metronome/Metronome.inf
- PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+ EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf {
+ <LibraryClasses>
+ RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
+ }
MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
<LibraryClasses>
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 9aa998f15f..1b62da2ec5 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -293,7 +293,7 @@ [FV.DXEFV]
INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
INF MdeModulePkg/Universal/Metronome/Metronome.inf
-INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 168+ messages in thread* Re: [edk2-devel] [PATCH v2 31/31] OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg
@ 2019-04-16 8:58 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-16 8:58 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> A Xen PVH guest doesn't have a RTC that OVMF would expect, so
> PcatRealTimeClockRuntimeDxe fails to initialize and prevent the firmware
> from finish to boot. To prevent that, we will use the
> XenRealTimeClockLib from ArmVirtPkg which simply always return the same
> time. This will work on both Xen PVH and HVM guests.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenOvmf.dsc | 5 ++++-
> OvmfPkg/XenOvmf.fdf | 2 +-
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 72d6ea8b29..14ef9ea9f2 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -577,7 +577,10 @@ [Components]
> }
> MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
> MdeModulePkg/Universal/Metronome/Metronome.inf
> - PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> + EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf {
> + <LibraryClasses>
> + RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> + }
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
> MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
> <LibraryClasses>
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index 9aa998f15f..1b62da2ec5 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -293,7 +293,7 @@ [FV.DXEFV]
> INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
> INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
> INF MdeModulePkg/Universal/Metronome/Metronome.inf
> -INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>
> INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>
(1) I suggest following "ArmVirtXen.dsc", that is, please resolve the
RealTimeClockLib class to XenRealTimeClockLib.inf globally, under
[LibraryClasses].
With that,
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v2 31/31] OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg
@ 2019-04-16 8:58 ` Laszlo Ersek
0 siblings, 0 replies; 168+ messages in thread
From: Laszlo Ersek @ 2019-04-16 8:58 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Jordan Justen, Julien Grall, xen-devel, Ard Biesheuvel
On 04/09/19 13:08, Anthony PERARD wrote:
> A Xen PVH guest doesn't have a RTC that OVMF would expect, so
> PcatRealTimeClockRuntimeDxe fails to initialize and prevent the firmware
> from finish to boot. To prevent that, we will use the
> XenRealTimeClockLib from ArmVirtPkg which simply always return the same
> time. This will work on both Xen PVH and HVM guests.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/XenOvmf.dsc | 5 ++++-
> OvmfPkg/XenOvmf.fdf | 2 +-
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 72d6ea8b29..14ef9ea9f2 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -577,7 +577,10 @@ [Components]
> }
> MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
> MdeModulePkg/Universal/Metronome/Metronome.inf
> - PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> + EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf {
> + <LibraryClasses>
> + RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> + }
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
> MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
> <LibraryClasses>
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index 9aa998f15f..1b62da2ec5 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -293,7 +293,7 @@ [FV.DXEFV]
> INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
> INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
> INF MdeModulePkg/Universal/Metronome/Metronome.inf
> -INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>
> INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>
(1) I suggest following "ArmVirtXen.dsc", that is, please resolve the
RealTimeClockLib class to XenRealTimeClockLib.inf globally, under
[LibraryClasses].
With that,
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 168+ messages in thread