Re: [PATCH v4 12/35] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct

Roger Pau Monné

On Thu, Aug 08, 2019 at 11:26:41AM +0100, Anthony PERARD wrote:
On Wed, Aug 07, 2019 at 04:35:58PM +0200, Roger Pau Monné wrote:
On Mon, Jul 29, 2019 at 04:39:21PM +0100, 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.
You seem to change the types when importing start_info.h, is that
absolutely necessary?
I guess one could try to map xen's types to EDKII's type with typedefs,
but I'm not sur how well that would work. Importing the xen headers is
documented so changing the types is fairly easy, see

Also, changing the header further might have been something useful to
do, we could have match EDKII's naming convention and source files would
have looked a bit less weird.
Ack, didn't know there was a README for this procedure.

From my experience working with different projects when importing such
headers it's better to keep them verbatim, this makes importing future
versions from upstream easier.

I have a comment below, but it's more like a question.

diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 5c7d7ddc1c..b366139a0a 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -25,6 +25,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"
@@ -86,6 +87,7 @@ XenConnect (
UINT32 XenVersion;
CHAR8 Sig[sizeof (Info->Signature) + 1];
+ UINT32 *PVHResetVectorData;

AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
@@ -121,6 +123,29 @@ 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 (PcdXenPvhStartOfDayStructPtr);
+ //
+ // That magic value is written in XenResetVector/Ia32/XenPVHMain.asm
+ //
+ if (PVHResetVectorData[1] == SIGNATURE_32 ('X', 'P', 'V', 'H')) {
+ 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;
I guess you can do this because OVMF has an identity map of virtual
addresses to physical addresses?
I think so, yes. I know that early code does created page table like
that, but I don't know if later code rework those page table or not.

I wonder the size of such identity map, and whether you need to check
that the rsdp address is indeed inside of that region before
converting it to a pointer. The same would apply to
PcdXenPvhStartOfDayStructPtr, but that's likely safe because it's
always < 4GB, which I assume OVMF always has identity mapped?
PcdXenPvhStartOfDayStructPtr is safe because OVMF owns it. As for the
rspd_paddr* and the HVMStartInfo*, I need to check. As you say, it's
probably fine as long as it's <4GB.

I've looked at the comment here:
This mean that the code executed in the patch (accessing the hvm start
info struct) is executed while the id map is setup up to 4GB. So as long
as the struct is below 4G, it's fine.
Yes, the start_info struct is guaranteed to be below 4GB because the
physical memory address of it is passed on a register when starting
the kernel in 32bit protected mode, so the address cannot be greater
than 4GB or it would be truncated.

As for the RSDP, I think that pointer is accessed much later, when a
different page table is setup, I think that would be that code:
But I'm not sure how much is setup. But I'm guessing that whatever is
pointed by RSDP, it will be in the 1:1, because we tell the UEFI about
it while parsing the e820.
OK, as long as we know it's safe to access. Note it's quite likely the
rsdp is also below 4GB anyway, but better be safe than sorry.

Thanks, Roger.

Join to automatically receive all group messages.