On Tue, 2023-01-17 at 15:38 +0100, kra...@redhat.com wrote:
> On Tue, Jan 17, 2023 at 02:10:08PM +0000, Boeuf, Sebastien wrote:
> > Hi,
> >
> > Looking at the hardcoded limitation provided by PcdPciMmio64Size
> > (32GiB), I was wondering what would be the best approach
From: Sebastien Boeuf
The address space width isn't properly calculated when the platform is
Cloud Hypervisor. The function PlatformAddressWidthFromCpuid() must not
be invoked with the QemuQuirk boolean set to true in the Cloud
Hypervisor case.
Relying on the host bridge identifier, we can set t
Hi,
Looking at the hardcoded limitation provided by PcdPciMmio64Size
(32GiB), I was wondering what would be the best approach to make this a
bit more dynamic?
I know that for QEMU, the fw_cfg mechanism can be used to override the
value of PcdPciMmio64Size, but this isn't something Cloud Hyperviso
On Wed, 2023-01-11 at 09:22 +0800, Min Xu wrote:
> From: Min M Xu
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4237
>
> Installation of gQemuAcpiTableNotifyProtocol may fail. The error code
> should be returned so that the caller can handle it.
>
> Cc: Erdem Aktas
> Cc: James Bottoml
On Wed, 2023-01-11 at 09:22 +0800, Min Xu wrote:
> From: Min M Xu
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4237
>
> The handle of mChAcpiHandle is not needed for anything, beyond the
> scope of the InstallCloudHvTablesTdx (). A local variable
> (ChAcpiHandle)
> suffices for storing
On Wed, 2023-01-11 at 09:22 +0800, Min Xu wrote:
> From: Min M Xu
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4237
>
> The QEMU_ACPI_TABLE_NOTIFY_PROTOCOL structure is superfluous because
> NULL
> protocol interfaces have been used in edk2 repeatedly. A protocol
> instance
> can exist
Thank you Min :)
From: Xu, Min M
Sent: Tuesday, January 3, 2023 12:18:27 AM
To: Boeuf, Sebastien ; Ard Biesheuvel
; devel@edk2.groups.io
Cc: Yao, Jiewen ; kra...@redhat.com
Subject: RE: [edk2-devel] [PATCH v2 0/3] OvmfPkg: Make IntelTdx work with Cloud
.
Thanks
Min
> -Original Message-
> From: Ard Biesheuvel
> Sent: Thursday, December 22, 2022 7:05 PM
> To: devel@edk2.groups.io; Boeuf, Sebastien
> Cc: Yao, Jiewen ; Xu, Min M ;
> kra...@redhat.com
> Subject: Re: [edk2-devel] [PATCH v2 0/3] OvmfPkg: Make IntelTdx work wi
Thank you Jiewen :)
From: Yao, Jiewen
Sent: Friday, December 16, 2022 4:03:00 AM
To: Boeuf, Sebastien ; devel@edk2.groups.io
Cc: Xu, Min M ; kra...@redhat.com
Subject: RE: [PATCH v2 0/3] OvmfPkg: Make IntelTdx work with Cloud Hypervisor
Merged: https
Hi Jiewen,
Thanks to Min, I've been able to fix the remaining issues.
I've just sent a v2 after I've verified the CI was passing correctly.
Thanks,
Sebastien
From: Yao, Jiewen
Sent: Thursday, December 15, 2022 3:02 AM
To: Boeuf, Sebastien ; devel
From: Sebastien Boeuf
This is required for passing the ACPI tables from the VMM up to the
guest OS. They are transferred through this GUID extension.
Signed-off-by: Jiaqi Gao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/Library/PlatformInitLib/IntelTdx.c | 5 +
1 file changed, 5 insertions(
From: Sebastien Boeuf
Rely on CcProbe() to identify when running on TDX so that ACPI tables
can be retrieved differently for Cloud Hypervisor. Instead of relying on
the PVH structure to find the RSDP pointer, the tables are individually
passed through the HOB.
Signed-off-by: Jiaqi Gao
Signed-of
From: Sebastien Boeuf
Rely on the CcProbe() function to identify when running on TDX. This
allows the firmware to follow a different codepath for Cloud Hypervisor,
which means it doesn't rely on PVH to find out about memory below 4GiB.
instead it falls back onto the CMOS to retrieve that informat
From: Sebastien Boeuf
The IntelTdxX64 OVMF target wasn't working with Cloud Hypervisor on TDX
platform. This was due to the way the OVMF code expects Cloud Hypervisor
to rely on PVH to retrieve information like memory below 4GiB as well as
the ACPI tables.
This is why this series takes care of i
From: Sebastien Boeuf
Rely on CcProbe() to identify when running on TDX so that ACPI tables
can be retrieved differently for Cloud Hypervisor. Instead of relying on
the PVH structure to find the RSDP pointer, the tables are individually
passed through the HOB.
Signed-off-by: Jiaqi Gao
Signed-of
From: Sebastien Boeuf
This is required for passing the ACPI tables from the VMM up to the
guest OS. They are transferred through this GUID extension.
Signed-off-by: Jiaqi Gao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/Library/PlatformInitLib/IntelTdx.c | 5 +
1 file changed, 5 insertions(
From: Sebastien Boeuf
Rely on the CcProbe() function to identify when running on TDX. This
allows the firmware to follow a different codepath for Cloud Hypervisor,
which means it doesn't rely on PVH to find out about memory below 4GiB.
instead it falls back onto the CMOS to retrieve that informat
From: Sebastien Boeuf
The IntelTdxX64 OVMF target wasn't working with Cloud Hypervisor on TDX
platform. This was due to the way the OVMF code expects Cloud Hypervisor
to rely on PVH to retrieve information like memory below 4GiB as well as
the ACPI tables.
This is why this series takes care of i
Ok sounds good.
Thanks,
Sebastien
From: Yao, Jiewen
Sent: Wednesday, September 7, 2022 5:23 PM
To: Boeuf, Sebastien
Cc: kra...@redhat.com ; Justen, Jordan L
; devel@edk2.groups.io
Subject: RE: [PATCH v2] OvmfPkg: Update I/O port related to ACPI devices for
Address. (from
> > MCFG).https://github.com/tianocore/edk2/blob/master/UefiPayloadPk
> > g/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAcpiBoa
> > rdInfo.c#L55
> >
> >
> > Thank you
> > Yao Jiewen
> >
> >
> > From: Boeuf,
fo/PciSegmentInfoLibAcpiBoa
> rdInfo.c#L55
>
>
> Thank you
> Yao Jiewen
>
>
> From: Boeuf, Sebastien
> Sent: Tuesday, September 6, 2022 11:41 PM
> To: Yao, Jiewen
> Cc: Justen, Jordan L ; kra...@redhat.com;
> devel@edk2.groups.io
> Subject: Re: [PATCH v
Sounds good, I'll have a look at these tomorrow and I'll try to come up with a
proper patch :)
Thanks,
Sebastien
From: Yao, Jiewen
Sent: Tuesday, September 6, 2022 5:57:16 PM
To: Boeuf, Sebastien
Cc: Justen, Jordan L ; kra...@redhat.com
; devel@edk2
there's some code already doing that in OVMF?
Thanks,
Sebastien
From: Yao, Jiewen
Sent: Tuesday, September 6, 2022 4:27 PM
To: Boeuf, Sebastien
Cc: Justen, Jordan L ; kra...@redhat.com
; devel@edk2.groups.io
Subject: RE: [PATCH v2] OvmfPkg: Update I/O port re
Hi Jiewen,
Do you think this could be merged?
Thanks,
Sebastien
From: Boeuf, Sebastien
Sent: Friday, August 19, 2022 11:59 AM
To: devel@edk2.groups.io
Cc: Yao, Jiewen ; Justen, Jordan L
; kra...@redhat.com ; Boeuf,
Sebastien
Subject: [PATCH v2] OvmfPkg
From: Sebastien Boeuf
Both ACPI shutdown and ACPI PM timer devices has been moved to different
port addresses in the latest version of Cloud Hypervisor. These changes
need to be reflected on the OVMF firmware.
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/Include/Industry
On Mon, 2022-08-15 at 15:49 +0200, Gerd Hoffmann wrote:
> On Thu, Aug 11, 2022 at 02:40:57PM +0200, Boeuf, Sebastien wrote:
> > From: Sebastien Boeuf
> >
> > Both ACPI shutdown and ACPI PM timer devices has been moved to
> > different
> > port addresses in the l
From: Sebastien Boeuf
Both ACPI shutdown and ACPI PM timer devices has been moved to different
port addresses in the latest version of Cloud Hypervisor. These changes
need to be reflected on the OVMF firmware.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/Include/IndustryStandard/CloudHv.h | 4 ++
Thank you!
From: Yao, Jiewen
Sent: Friday, June 3, 2022 12:52 PM
To: Boeuf, Sebastien ; devel@edk2.groups.io
Cc: kra...@redhat.com ; Justen, Jordan L
Subject: RE: [PATCH 0/4] OvmfPkg: CloudHv: Reduce PIO and MMIO accesses
Merged https://github.com/tianocore
pull/2875
Thanks,
Sebastien
>
> Thanks,
> Sebastien
>
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Boeuf, Sebastien
> > > Sent: Tuesday, May 10, 2022 8:51 PM
> > > To: devel@edk2.groups.io
st master. I think the
failures were only related to the Windows CI issues.
Thanks,
Sebastien
>
> Thank you
> Yao Jiewen
>
> > -Original Message-
> > From: Boeuf, Sebastien
> > Sent: Tuesday, May 10, 2022 8:51 PM
> > To: devel@edk2.groups.io
> >
Hi,
Sorry to bother you folks, but I was wondering if you had this patchset on your
radar :)
Thanks for your time,
Sebastien
From: Boeuf, Sebastien
Sent: Tuesday, May 10, 2022 2:50 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen ; Justen, Jordan L
; kra
From: Sebastien Boeuf
There are few places in the codebase assuming QemuFwCfg will be present
and supported, which can cause some issues when trying to rely on the
QemuFwCfgLibNull implementation of QemuFwCfgLib.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/Library/PlatformInitLib/Platform.c
From: Sebastien Boeuf
Since Cloud Hypervisor doesn't emulate an A20 gate register on I/O port
0x92, it's better to avoid accessing it when the platform is identified
as Cloud Hypervisor.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/Library/PlatformInitLib/Platform.c | 4 +++-
1 file changed, 3 i
From: Sebastien Boeuf
Since Cloud Hypervisor doesn't support the fw_cfg mechanism, it's more
appropriate to rely on QemuFwCfgLibNull implementation of QemuFwCfgLib
since it provides a null implementation that will not issue any PIO
accesses to ports 0x510 and 0x511.
Signed-off-by: Sebastien Boeu
From: Sebastien Boeuf
The FW_BASE_ADDRESS value provided by OvmfPkgDefines.fdf.inc is
incorrect for the CloudHv target. We know the generated firmware
contains a PVH ELF header, meaning it will be loaded according to the
address provided through this header. And since we know this address
isn't g
unexpected
accesses to some address ranges.
For PIO accesses, it is about preventing some read/write to be performed
in the first place, as we know the underlying device is not emulated by
Cloud Hypervisor.
Signed-off-by: Sebastien Boeuf
Sebastien Boeuf (4):
OvmfPkg: CloudHv: Fix
On Mon, 2022-05-09 at 11:49 +0200, kra...@redhat.com wrote:
> On Mon, May 09, 2022 at 09:32:52AM +0000, Boeuf, Sebastien wrote:
> > Hi,
> >
> > I'm trying to debug OVMF with gdb connected to Cloud Hypervisor but
> > the
> > problem is that the debu
Hi,
I have a question related to the MMIO accesses performed by OVMF that I
can see are happening whenever PcdGet() is invoked. Could you tell me
how PCD works that can explain why I can see some MMIO read accesses on
address 0xFFFD5A24?
Also, I'm using the CloudHv target, meaning it's loaded as
Hi,
I'm trying to debug OVMF with gdb connected to Cloud Hypervisor but the
problem is that the debug binary that I have generated doesn't contain
any symbols. Do you know how to generate debug symbols for OVMF?
Thanks,
Sebastien
---
Acked-by: Sebastien Boeuf
On Fri, 2022-03-25 at 16:28 -0700, Judah Vang wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2594
>
> Add reference for ProtectedVariableLib.
>
> Cc: Jian J Wang
> Cc: Sebastien Boeuf
> Cc: Nishant C Mistry
> Signed-off-by: Judah Vang
> ---
> OvmfPkg
The series looks good to me, and I've tested your branch by building
CLOUDHV.fd and running it with Cloud Hypervisor, nothing's broken :)
Acked-by: Sebastien Boeuf
On Tue, 2022-03-08 at 10:36 +0800, Min Xu wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863
>
> There are 3 variants
From: Sebastien Boeuf
Instead of using the CMOS, the CloudHv platform relies on the list of
memmap entries provided through the PVH boot protocol to determine the
last RAM address below 4G.
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/PlatformPei/MemDetect.c | 73 +++
From: Sebastien Boeuf
Add some documentation to the CloudHv target in order to clarify how to
use it and what to expect from it.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/README | 67 ++
1 file changed, 67 insertions(+)
create mode 100644 OvmfP
From: Sebastien Boeuf
Instead of hardcoding the address of the RSDP in the firmware, let's
rely on the PVH structure hvm_start_info to retrieve this information.
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 ++
OvmfPkg/AcpiPlatfor
From: Sebastien Boeuf
Following the model from the Xen target, CloudHv is generated as a PVH
ELF binary to take advantage of the PVH specification, which requires
less emulation from the VMM.
The fdf include file CloudHvElfHeader.fdf.inc has been generated from
the following commands:
$ gcc -D
From: Sebastien Boeuf
Instead of having the PVH ELF header part of the fdf file directly, we
move it to a dedicated include file. This is the first step in
automating the generation of the header.
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/OvmfXen.fdf | 57 ++-
From: Sebastien Boeuf
CloudHv doesn't need any VARS store, and it doesn't need the CODE
section to be generated separately either. The only thing needed is to
generate a firmware binary that can be used by Cloud Hypervisor.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.fdf | 30
From: Sebastien Boeuf
Updating the fdf include file based on the run of the ELF header
generator. The diff from this patch is the result of:
$ gcc -o elf_gen OvmfPkg/OvmfXenElfHeaderGenerator.c
$ ./elf_gen 2097152 OvmfPkg/XenElfHeader.fdf.inc
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Bo
From: Sebastien Boeuf
Adding some flexibility to the program through optional parameters and
global define, so that other targets can use the generator.
* A global define is added so that we can choose at build time if we
want to use 32-bit or 64-bit base structures.
* A first optional paramet
Same thing for the RAM below 4G, we can find this information
through the PVH memmap entries rather than relying on the emulated CMOS.
Signed-off-by: Sebastien Boeuf
Sebastien Boeuf (8):
OvmfPkg: Make the Xen ELF header generator more flexible
OvmfPkg: Xen: Use a new fdf include for the PV
On Wed, 2022-03-02 at 08:17 +0100, Gerd Hoffmann wrote:
> > -[FD.CLOUDHV_VARS]
> > -[FD.CLOUDHV_CODE]
>
> Dropping these two should be a separate patch,
> so this patch becomes more readable.
Sounds good.
>
> > -0x|$(FVMAIN_SIZE)
> > +0x1000|$(FVMAIN_SIZE)
>
> FVMAIN_SIZE is not ch
On Tue, 2022-03-01 at 12:28 +0100, kra...@redhat.com wrote:
> On Tue, Mar 01, 2022 at 08:53:10AM +0000, Boeuf, Sebastien wrote:
> > On Tue, 2022-03-01 at 08:16 +0100, Gerd Hoffmann wrote:
> > > On Mon, Feb 28, 2022 at 03:12:53PM +, Boeuf, Sebastien wrote:
> > > >
From: Sebastien Boeuf
Add some documentation to the CloudHv target in order to clarify how to
use it and what to expect from it.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/README | 67 ++
1 file changed, 67 insertions(+)
create mode 100644 OvmfP
From: Sebastien Boeuf
Instead of using the CMOS, the CloudHv platform relies on the list of
memmap entries provided through the PVH boot protocol to determine the
last RAM address below 4G.
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/PlatformPei/MemDetect.c | 73 +++
From: Sebastien Boeuf
Instead of hardcoding the address of the RSDP in the firmware, let's
rely on the PVH structure hvm_start_info to retrieve this information.
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 ++
OvmfPkg/AcpiPlatfor
From: Sebastien Boeuf
Following the model from the Xen target, CloudHv is generated as a PVH
ELF binary to take advantage of the PVH specification, which requires
less emulation from the VMM.
The fdf include file CloudHvElfHeader.fdf.inc has been generated from
the following commands:
$ gcc -D
From: Sebastien Boeuf
Updating the fdf include file based on the run of the ELF header
generator. The diff from this patch is the result of:
$ gcc -o elf_gen OvmfPkg/OvmfXenElfHeaderGenerator.c
$ ./elf_gen 2097152 OvmfPkg/XenElfHeader.fdf.inc
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Bo
From: Sebastien Boeuf
Instead of having the PVH ELF header part of the fdf file directly, we
move it to a dedicated include file. This is the first step in
automating the generation of the header.
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/OvmfXen.fdf | 57 ++-
From: Sebastien Boeuf
Adding some flexibility to the program through optional parameters and
global define, so that other targets can use the generator.
* A global define is added so that we can choose at build time if we
want to use 32-bit or 64-bit base structures.
* A first optional paramet
Same thing for the RAM below 4G, we can find this information
through the PVH memmap entries rather than relying on the emulated CMOS.
Signed-off-by: Sebastien Boeuf
Sebastien Boeuf (7):
OvmfPkg: Make the Xen ELF header generator more flexible
OvmfPkg: Xen: Use a new fdf include for the PV
On Tue, 2022-03-01 at 08:53 +, Boeuf, Sebastien wrote:
> On Tue, 2022-03-01 at 08:16 +0100, Gerd Hoffmann wrote:
> > On Mon, Feb 28, 2022 at 03:12:53PM +0000, Boeuf, Sebastien wrote:
> > > So what do you think I should do with this patch?
> >
> > I thin
On Tue, 2022-03-01 at 08:16 +0100, Gerd Hoffmann wrote:
> On Mon, Feb 28, 2022 at 03:12:53PM +0000, Boeuf, Sebastien wrote:
> > So what do you think I should do with this patch?
>
> I think you can:
>
> (1) drop FD.CLOUDHV_VARS
Ok
> (2) drop FD.CLOUDHV_CODE
Ok
>
So what do you think I should do with this patch?
Thanks,
Sebastien
On Mon, 2022-02-28 at 08:15 +, Boeuf, Sebastien wrote:
> On Mon, 2022-02-28 at 08:08 +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > Oh. So the ELF header *replaces* the firmware volume header.
On Mon, 2022-02-28 at 08:08 +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > Oh. So the ELF header *replaces* the firmware volume header.
> > > Didn't notice that before.
> > >
> > > Hmm. With that the varstore initialization most likely fails.
> > > There is a fallback path though, with ovmf storin
Thank you Jiewen :)
From: Yao, Jiewen
Sent: Friday, February 25, 2022 3:21 PM
To: Boeuf, Sebastien ; kra...@redhat.com
; devel@edk2.groups.io
Cc: Justen, Jordan L
Subject: RE: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification
I updated release
On Fri, 2022-02-25 at 14:00 +0100, Gerd Hoffmann wrote:
> > +++ b/OvmfPkg/CloudHv/CloudHvX64.fdf
> > @@ -14,8 +14,8 @@
> > !include OvmfPkg/OvmfPkgDefines.fdf.inc
> >
> > #
> > -# Build the variable store and the firmware code as one unified
> > flash device
> > -# image.
> > +# This will allow
ore.github.io/wiki/EDK-II-Release-Planning
Do I need to send a PR to update the wiki?
>
> I suggestion you send a different email to ask the different topic -
> not distract people.
>
>
> > -----Original Message-
> > From: Boeuf, Sebastien
> > Sent: Wed
On Fri, 2022-02-25 at 10:29 +0100, kra...@redhat.com wrote:
> Hi,
>
> > > Hmm, VarStore.fdf.inc reduces duplication, and now you revert
> > > this.
> > > Maybe add this to VarStore.fdf.inc instead, and add a
> > > PVH_HEADER_ENABLE
> > > option to turn it on and off?
> >
> > It's quite hard to
From: Sebastien Boeuf
Instead of using the CMOS, the CloudHv platform relies on the list of
memmap entries provided through the PVH boot protocol to determine the
last RAM address below 4G.
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/PlatformPei/MemDetect.c | 73 +++
From: Sebastien Boeuf
Add some documentation to the CloudHv target in order to clarify how to
use it and what to expect from it.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/README | 67 ++
1 file changed, 67 insertions(+)
create mode 100644 OvmfP
From: Sebastien Boeuf
Instead of hardcoding the address of the RSDP in the firmware, let's
rely on the PVH structure hvm_start_info to retrieve this information.
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 ++
OvmfPkg/AcpiPlatfor
From: Sebastien Boeuf
Following the model from the Xen target, CloudHv is generated as a PVH
ELF binary to take advantage of the PVH specification, which requires
less emulation from the VMM.
The fdf include file CloudHvElfHeader.fdf.inc has been generated from
the following commands:
$ gcc -D
From: Sebastien Boeuf
Updating the fdf include file based on the run of the ELF header
generator. The diff from this patch is the result of:
$ gcc -o elf_gen OvmfPkg/OvmfXenElfHeaderGenerator.c
$ ./elf_gen 2097152 OvmfPkg/XenElfHeader.fdf.inc
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Bo
From: Sebastien Boeuf
Instead of having the PVH ELF header part of the fdf file directly, we
move it to a dedicated include file. This is the first step in
automating the generation of the header.
Acked-by: Gerd Hoffmann
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/OvmfXen.fdf | 57 ++-
From: Sebastien Boeuf
Adding some flexibility to the program through optional parameters and
global define, so that other targets can use the generator.
* A global define is added so that we can choose at build time if we
want to use 32-bit or 64-bit base structures.
* A first optional paramet
Same thing for the RAM below 4G, we can find this information
through the PVH memmap entries rather than relying on the emulated CMOS.
Signed-off-by: Sebastien Boeuf
Sebastien Boeuf (7):
OvmfPkg: Make the Xen ELF header generator more flexible
OvmfPkg: Xen: Use a new fdf include for the PV
On Fri, 2022-02-25 at 10:43 +0100, Gerd Hoffmann wrote:
> On Thu, Feb 24, 2022 at 03:28:26PM +0100,
> sebastien.bo...@intel.com wrote:
> > From: Sebastien Boeuf
> >
> > Add some documentation to the CloudHv target in order to clarify
> > how to
> > use it and what to expect from it.
> >
> > Sign
On Thu, 2022-02-24 at 09:16 +0100, Gerd Hoffmann wrote:
> Hi,
>
> > -!include OvmfPkg/VarStore.fdf.inc
> > +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
> > +0x|0xe000
> > +!endif
> > +!if $(FD_SIZE_IN_KB) == 4096
> > +0x|0x0004
> > +!endif
>
> Hmm, VarSt
On Wed, 2022-02-23 at 12:31 +0100, Gerd Hoffmann wrote:
> Hi,
>
> > + PVHResetVectorData = (VOID *)(UINTN)PcdGet32
> > (PcdXenPvhStartOfDayStructPtr);
> > + pvh_start_info = (struct hvm_start_info
> > *)(UINTN)PVHResetVectorData[0];
>
> Ah, I see, here is the xen reset vector dependency
On Thu, 2022-02-24 at 07:27 +0100, Gerd Hoffmann wrote:
> > > > +DATA = {
> > > > + #
> > > > + # This hex array have been generated by
> > > > OvmfPkg/OvmfXenElfHeaderGenerator.c
> > > > + # and copied manually.
> > >
> > > How about having the generator write a .fdf.inc file which you
> > > c
From: Sebastien Boeuf
Add some documentation to the CloudHv target in order to clarify how to
use it and what to expect from it.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/README | 66 ++
1 file changed, 66 insertions(+)
create mode 100644 OvmfP
From: Sebastien Boeuf
Instead of using the CMOS, the CloudHv platform relies on the list of
memmap entries provided through the PVH boot protocol to determine the
last RAM address below 4G.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/PlatformPei/MemDetect.c | 73
From: Sebastien Boeuf
Instead of hardcoding the address of the RSDP in the firmware, let's
rely on the PVH structure hvm_start_info to retrieve this information.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 ++
OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
From: Sebastien Boeuf
Following the model from the Xen target, CloudHv is generated as a PVH
ELF binary to take advantage of the PVH specification, which requires
less emulation from the VMM.
The fdf include file CloudHvElfHeader.fdf.inc has been generated from
the following commands:
$ gcc -D
From: Sebastien Boeuf
Updating the fdf include file based on the run of the ELF header
generator. The diff from this patch is the result of:
$ gcc -o elf_gen OvmfPkg/OvmfXenElfHeaderGenerator.c
$ ./elf_gen 2097152 OvmfPkg/XenElfHeader.fdf.inc
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/XenElfH
From: Sebastien Boeuf
Instead of having the PVH ELF header part of the fdf file directly, we
move it to a dedicated include file. This is the first step in
automating the generation of the header.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/OvmfXen.fdf | 57 ++--
From: Sebastien Boeuf
Adding some flexibility to the program through optional parameters and
global define, so that other targets can use the generator.
* A global define is added so that we can choose at build time if we
want to use 32-bit or 64-bit base structures.
* A first optional paramet
Same thing for the RAM below 4G, we can find this information
through the PVH memmap entries rather than relying on the emulated CMOS.
Signed-off-by: Sebastien Boeuf
Sebastien Boeuf (7):
OvmfPkg: Make the Xen ELF header generator more flexible
OvmfPkg: Xen: Use a new fdf include for the PV
On Wed, 2022-02-23 at 13:35 +0100, Sebastien Boeuf wrote:
> On Wed, 2022-02-23 at 12:22 +0100, Gerd Hoffmann wrote:
> > On Tue, Feb 22, 2022 at 04:53:04PM +0100, Boeuf, Sebastien wrote:
> > > From: Sebastien Boeuf
> > >
> > > Following the model from the
From: Sebastien Boeuf
Following the model from the Xen target, CloudHv is generated as a PVH
ELF binary to take advantage of the PVH specification.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 2 +-
OvmfPkg/CloudHv/CloudHvX64.fdf | 94 +-
From: Sebastien Boeuf
Instead of using the CMOS, the CloudHv platform relies on the list of
memmap entries provided through the PVH boot protocol to determine the
last RAM address below 4G.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/PlatformPei/MemDetect.c | 73
ou send a different email to ask the different topic -
> not distract people.
Sorry, I'll send a separate email.
Thanks,
Sebastien
>
>
> > -----Original Message-
> > From: Boeuf, Sebastien
> > Sent: Wednesday, February 23, 2022 10:03 PM
> > To: kra...@
From: Sebastien Boeuf
Instead of hardcoding the address of the RSDP in the firmware, let's
rely on the PVH structure hvm_start_info to retrieve this information.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 ++
OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
From: Sebastien Boeuf
Adding some flexibility to the program so that other targets can use it
if needed.
An optional size parameter is added so that we can provide the expected
blob size of the generated binary.
A global define is added so that we can choose at build time if we want
to use 32-b
From: Sebastien Boeuf
Add some documentation to the CloudHv target in order to clarify how to
use it and what to expect from it.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/README | 66 ++
1 file changed, 66 insertions(+)
create mode 100644 OvmfP
Same thing for the RAM below 4G, we can find this information
through the PVH memmap entries rather than relying on the emulated CMOS.
Signed-off-by: Sebastien Boeuf
Sebastien Boeuf (5):
OvmfPkg: Make the Xen ELF header generator more flexible
OvmfPkg: Generate CloudHv as a PVH ELF binary
Ov
ovm is a good example -
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Microvm/README.
>
> Thank you
> Yao Jiewen
>
> > -Original Message-
> > From: Boeuf, Sebastien
> > Sent: Wednesday, February 23, 2022 8:20 PM
> > To: kra...@redhat.com; deve
On Wed, 2022-02-23 at 12:22 +0100, Gerd Hoffmann wrote:
> On Tue, Feb 22, 2022 at 04:53:04PM +0100, Boeuf, Sebastien wrote:
> > From: Sebastien Boeuf
> >
> > Following the model from the Xen target, CloudHv is generated as a
> > PVH
> > ELF binary to take a
On Wed, 2022-02-23 at 13:02 +0100, kra...@redhat.com wrote:
> Hi,
>
> > Well that's a good question. If we expect the same target (CloudHv)
> > to
> > support both TDX and non-TDX, that means the generated TDVF will be
> > a
> > PVH ELF binary, which will require some special handling from Cloud
rget cover both use cases?
Thanks,
Sebastien
>
> Thank you
> Yao, Jiewen
>
> > -Original Message-
> > From: Boeuf, Sebastien
> > Sent: Tuesday, February 22, 2022 11:53 PM
> > To: devel@edk2.groups.io
> > Cc: Yao, Jiewen ; Justen, Jordan
1 - 100 of 178 matches
Mail list logo
