All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: devel@edk2.groups.io, anthony.perard@citrix.com
Cc: Jordan Justen <jordan.l.justen@intel.com>,
	Julien Grall <julien.grall@arm.com>,
	xen-devel@lists.xenproject.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [edk2-devel] [PATCH v2 22/31] OvmfPkg/XenPlatformPei: Rework memory detection
Date: Fri, 12 Apr 2019 13:15:48 +0200	[thread overview]
Message-ID: <eed1a0b8-5c18-93a9-11f3-5ef8db05f5f4@redhat.com> (raw)
In-Reply-To: <20190409110844.14746-23-anthony.perard@citrix.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Laszlo Ersek <lersek@redhat.com>
To: devel@edk2.groups.io, anthony.perard@citrix.com
Cc: Jordan Justen <jordan.l.justen@intel.com>,
	Julien Grall <julien.grall@arm.com>,
	xen-devel@lists.xenproject.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [Xen-devel] [edk2-devel] [PATCH v2 22/31] OvmfPkg/XenPlatformPei: Rework memory detection
Date: Fri, 12 Apr 2019 13:15:48 +0200	[thread overview]
Message-ID: <eed1a0b8-5c18-93a9-11f3-5ef8db05f5f4@redhat.com> (raw)
Message-ID: <20190412111548.2DsGfiH3qaBJTiliNugO3DRIVIPDtT31UFLl0SGli_s@z> (raw)
In-Reply-To: <20190409110844.14746-23-anthony.perard@citrix.com>

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

  reply	other threads:[~2019-04-12 11:16 UTC|newest]

Thread overview: 168+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09 11:08 [PATCH v2 00/31] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
2019-04-09 11:08 ` [Xen-devel] " Anthony PERARD
2019-04-09 11:08 ` [PATCH v2 01/31] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-10  8:48   ` [edk2-devel] " Laszlo Ersek
2019-04-10  8:48     ` [Xen-devel] " Laszlo Ersek
2019-04-10  9:16     ` Jordan Justen
2019-04-10  9:16       ` [Xen-devel] " Jordan Justen
2019-04-09 11:08 ` [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-10  9:32   ` [edk2-devel] " Laszlo Ersek
2019-04-10  9:32     ` [Xen-devel] " Laszlo Ersek
2019-04-15 10:53     ` Anthony PERARD
2019-04-15 10:53       ` [Xen-devel] " Anthony PERARD
2019-04-10  9:48   ` Jordan Justen
2019-04-10  9:48     ` [Xen-devel] " Jordan Justen
2019-04-10 14:27     ` Laszlo Ersek
2019-04-10 14:27       ` [Xen-devel] " Laszlo Ersek
2019-04-10 16:27       ` Ard Biesheuvel
2019-04-10 16:27         ` [Xen-devel] " Ard Biesheuvel
2019-04-10 18:37       ` Jordan Justen
2019-04-10 18:37         ` [Xen-devel] " Jordan Justen
2019-04-11  7:34         ` Laszlo Ersek
2019-04-11  7:34           ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 03/31] OvmfPkg: Introduce XenResetVector Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-10  9:46   ` [edk2-devel] " Laszlo Ersek
2019-04-10  9:46     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 04/31] OvmfPkg: Introduce XenPlatformPei Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-10 10:37   ` [edk2-devel] " Laszlo Ersek
2019-04-10 10:37     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 05/31] OvmfPkg/XenOvmf: Creating an ELF header Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-11 10:43   ` [edk2-devel] " Laszlo Ersek
2019-04-11 10:43     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-11 10:49   ` [edk2-devel] " Laszlo Ersek
2019-04-11 10:49     ` [Xen-devel] " Laszlo Ersek
2019-04-11 12:52   ` Andrew Cooper
2019-04-11 12:52     ` [Xen-devel] " Andrew Cooper
2019-04-15 11:25     ` Anthony PERARD
2019-04-15 11:25       ` [Xen-devel] " Anthony PERARD
2019-04-15 13:28       ` Andrew Cooper
2019-04-15 13:28         ` [Xen-devel] " Andrew Cooper
2019-04-09 11:08 ` [PATCH v2 07/31] OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-11 11:09   ` [edk2-devel] " Laszlo Ersek
2019-04-11 11:09     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 08/31] OvmfPkg/XenResetVector: Allow to jumpstart from either hvmloader or PVH Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-11 11:19   ` [edk2-devel] " Laszlo Ersek
2019-04-11 11:19     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 09/31] OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-11 11:25   ` [edk2-devel] " Laszlo Ersek
2019-04-11 11:25     ` [Xen-devel] " Laszlo Ersek
2019-04-11 11:33     ` Laszlo Ersek
2019-04-11 11:33       ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 10/31] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-11 11:47   ` [edk2-devel] " Laszlo Ersek
2019-04-11 11:47     ` [Xen-devel] " Laszlo Ersek
2019-04-11 11:47     ` Laszlo Ersek
2019-04-11 11:47       ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 11/31] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820 Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-11 11:49   ` [edk2-devel] " Laszlo Ersek
2019-04-11 11:49     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 12/31] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-11 11:58   ` [edk2-devel] " Laszlo Ersek
2019-04-11 11:58     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 13/31] OvmfPkg/Library/XenPlatformLib: New library Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-11 12:10   ` [edk2-devel] " Laszlo Ersek
2019-04-11 12:10     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-11 12:20   ` [edk2-devel] " Laszlo Ersek
2019-04-11 12:20     ` [Xen-devel] " Laszlo Ersek
2019-04-11 12:23     ` Laszlo Ersek
2019-04-11 12:23       ` [Xen-devel] " Laszlo Ersek
2019-04-11 12:31       ` Laszlo Ersek
2019-04-11 12:31         ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 15/31] OvmfPkg/XenHypercallLib: Enable it in PEIM Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-12  9:07   ` [edk2-devel] " Laszlo Ersek
2019-04-12  9:07     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 16/31] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-12  9:08   ` [edk2-devel] " Laszlo Ersek
2019-04-12  9:08     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 17/31] OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it as runned Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-12  9:09   ` [edk2-devel] " Laszlo Ersek
2019-04-12  9:09     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 18/31] OvmfPkg/XenPlatformPei: Setup HyperPages earlier Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-12  9:17   ` [edk2-devel] " Laszlo Ersek
2019-04-12  9:17     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 19/31] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-12  9:20   ` [edk2-devel] " Laszlo Ersek
2019-04-12  9:20     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 20/31] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-12  9:22   ` [edk2-devel] " Laszlo Ersek
2019-04-12  9:22     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 21/31] OvmfPkg/XenPlatformPei: Get E820 table via hypercall Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-12  9:33   ` [edk2-devel] " Laszlo Ersek
2019-04-12  9:33     ` [Xen-devel] " Laszlo Ersek
2019-04-12  9:45     ` Andrew Cooper
2019-04-12  9:45       ` [Xen-devel] " Andrew Cooper
2019-04-09 11:08 ` [PATCH v2 22/31] OvmfPkg/XenPlatformPei: Rework memory detection Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-12 11:15   ` Laszlo Ersek [this message]
2019-04-12 11:15     ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-04-15 13:42     ` Anthony PERARD
2019-04-15 13:42       ` [Xen-devel] " Anthony PERARD
2019-04-09 11:08 ` [PATCH v2 23/31] OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-15 13:21   ` [edk2-devel] " Laszlo Ersek
2019-04-15 13:21     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 24/31] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-15 13:29   ` [edk2-devel] " Laszlo Ersek
2019-04-15 13:29     ` [Xen-devel] " Laszlo Ersek
2019-04-15 13:33     ` Laszlo Ersek
2019-04-15 13:33       ` [Xen-devel] " Laszlo Ersek
2019-04-15 13:37   ` Andrew Cooper
2019-04-15 13:37     ` [Xen-devel] " Andrew Cooper
2019-04-09 11:08 ` [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus " Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-15 13:33   ` [edk2-devel] " Laszlo Ersek
2019-04-15 13:33     ` [Xen-devel] " Laszlo Ersek
2019-04-15 13:49     ` Laszlo Ersek
2019-04-15 13:49       ` [Xen-devel] " Laszlo Ersek
2019-04-15 14:40       ` Anthony PERARD
2019-04-15 14:40         ` [Xen-devel] " Anthony PERARD
2019-04-15 17:57         ` Laszlo Ersek
2019-04-15 17:57           ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 26/31] OvmfPkg/XenOvmf: Override PcdFSBClock to Xen vLAPIC timer frequency Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-15 13:52   ` [edk2-devel] " Laszlo Ersek
2019-04-15 13:52     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 27/31] OvmfPkg/XenOvmf: Introduce XenTimerDxe Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-15 14:07   ` [edk2-devel] " Laszlo Ersek
2019-04-15 14:07     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 28/31] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-15 14:56   ` [edk2-devel] " Laszlo Ersek
2019-04-15 14:56     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 29/31] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-16  8:49   ` [edk2-devel] " Laszlo Ersek
2019-04-16  8:49     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 30/31] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-16  8:53   ` [edk2-devel] " Laszlo Ersek
2019-04-16  8:53     ` [Xen-devel] " Laszlo Ersek
2019-04-09 11:08 ` [PATCH v2 31/31] OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg Anthony PERARD
2019-04-09 11:08   ` [Xen-devel] " Anthony PERARD
2019-04-16  8:58   ` [edk2-devel] " Laszlo Ersek
2019-04-16  8:58     ` [Xen-devel] " Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eed1a0b8-5c18-93a9-11f3-5ef8db05f5f4@redhat.com \
    --to=lersek@redhat.com \
    --cc=anthony.perard@citrix.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=devel@edk2.groups.io \
    --cc=jordan.l.justen@intel.com \
    --cc=julien.grall@arm.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.