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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Include/IndustryStandard/Xen/README
> 
> 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;
> > >    EFI_XEN_OVMF_INFO *Info;
> > >    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:
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/ResetVector/Ia32/PageTables64.asm#L94
> 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:
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel