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
Address. (from
> > MCFG).https://github.com/tianocore/edk2/blob/master/UefiPayloadPk
> > g/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAcpiBoa
> > rdInfo.c#L55
> >
> >
> > Thank you
> > Yao Jiewen
> >
> >
> > From: Boeuf,
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
I've just rebased the PR and sent a v6 version.
Thanks,
Sebastien
From: Yao, Jiewen
Sent: Thursday, December 9, 2021 7:41 AM
To: Boeuf, Sebastien ; devel@edk2.groups.io
Cc: Justen, Jordan L ; kra...@redhat.com
Subject: RE: [PATCH v5 0/5] Add Cloud Hyper
Ah yes I'm sorry I forgot to update each patch with the uncrustify tool.
I'm going to send a v7 as soon as the CI confirms the new series complies with
the CI.
Thanks,
Sebastien
From: Yao, Jiewen
Sent: Friday, December 10, 2021 1:47 PM
To: Boeuf,
From: Sebastien Boeuf
This series aims at adding the support for the Cloud Hypervisor platform
to the OVMF firmware for x86 architecture.
The goal is to allow the same binary to be used either by QEMU or Cloud
Hypervisor, using the Cloud Hypervisor way as a fallback if the fw_cfg
mechanism is no
From: Sebastien Boeuf
Handle things differently when the detected host bridge matches the
Cloud Hypervisor PCI host bridge identifier.
Reviewed-by: Gerd Hoffmann
Reviewed-by: Jiewen Yao
Signed-off-by: Rob Bradford
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/Include/IndustryStandard/CloudHv.h
From: Sebastien Boeuf
Move the generic entry point part out of Qemu.c to anticipate the
addition of new ways of retrieving the SMBIOS table.
Reviewed-by: Gerd Hoffmann
Reviewed-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/SmbiosPlatformDxe/EntryPoint.c| 42 ++
From: Sebastien Boeuf
Add a fallback on the SMBIOS code to find the SMBIOS table for Cloud
Hypervisor if it couldn't be found for Qemu through fw_cfg.
Reviewed-by: Gerd Hoffmann
Reviewed-by: Jiewen Yao
Signed-off-by: Rob Bradford
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/Include/IndustrySt
From: Sebastien Boeuf
Adding support for retrieving the Cloud Hypervisor ACPI tables as a
fallback mechanism if tables are not found through fw_cfg.
Reviewed-by: Gerd Hoffmann
Reviewed-by: Jiewen Yao
Signed-off-by: Rob Bradford
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/AcpiPlatformDxe/Acpi
From: Sebastien Boeuf
Don't make the package Qemu centric so that we can introduce some
alternative support for other VMMs not using the fw_cfg mechanism.
This patch is purely about renaming existing files with no functional
change.
Reviewed-by: Gerd Hoffmann
Reviewed-by: Jiewen Yao
Signed-of
Hi Gerd,
Your patch 41d8bb30386ceab55787fc9f5aac6434e2493e27 removing the CMOS
support for getting high mem and low mem is breaking the OVMF support for
Cloud Hypervisor as we are still providing this information through that
mechanism.
Do you think it would be acceptable to revert it in order t
Thank you! I really appreciate your responsiveness!
Sebastien
From: Yao, Jiewen
Sent: Wednesday, December 15, 2021 6:14:07 PM
To: devel@edk2.groups.io ; a...@kernel.org
; Boeuf, Sebastien
Cc: kra...@redhat.com
Subject: RE: [edk2-devel] CMOS needed for Cloud
Hi folks,
I was wondering if you would be okay with me adding Cloud Hypervisor to the
EDK2 CI.
The idea would be to run a quick/simple test that Cloud Hypervisor can properly
boot
with the OVMF binary built from source on every pull request.
And if you think that makes sense, any guidance on ho
Wednesday, January 5, 2022 12:40 AM
To: devel@edk2.groups.io ; Boeuf, Sebastien
; Yao, Jiewen ;
kra...@redhat.com
Subject: Re: [edk2-devel] Guidance about CI
can cloud hypervisor boot on any of the free CI providers?
If you look at ArmVirt, Ovmf, and even the emulatorpkg those all do
similar thing
lf of Boeuf, Sebastien
Sent: Wednesday, January 5, 2022 2:32 PM
To: devel@edk2.groups.io ; Yao, Jiewen
; kra...@redhat.com ;
spbro...@outlook.com
Subject: Re: [edk2-devel] Guidance about CI
Hi Sean,
Cloud Hypervisor can boot on Microsoft Azure VMs as this is what our project
relies on to val
Hi Gerd,
I was looking at a way to add support for EFI shell interaction with Cloud
Hypervisor when
I realized you added the support for microvm with commit 55f47d22998.
I have been able to hack OvmfPkgX64 similarly to get it to work, but here are
two follow up
questions:
1. Is it possible to s
On Thu, 2022-01-06 at 13:44 +0100, kra...@redhat.com wrote:
> On Thu, Jan 06, 2022 at 11:25:37AM +0000, Boeuf, Sebastien wrote:
> > Hi Gerd,
> >
> > I was looking at a way to add support for EFI shell interaction
> > with Cloud Hypervisor when
> > I realized you a
On Wed, 2022-01-05 at 17:55 +0100, kra...@redhat.com wrote:
> On Wed, Jan 05, 2022 at 01:44:01PM +0000, Boeuf, Sebastien wrote:
> > Ah nevermind I found out QEMU was installed from packaging.
>
> On ubuntu.
>
> > We don't have packages for Cloud Hypervisor, but
On Fri, 2022-01-07 at 13:07 +0100, kra...@redhat.com wrote:
> Hi,
>
> > > microvm has no lpc bridge, so I had to do it in a different way
> > > ...
> >
> > Cloud Hypervisor doesn't emulate any LPC bridge or ISA bus.
>
> Ok, doing it microvm-style makes sense then.
Ok thanks for the confirmati
On Fri, 2022-01-07 at 13:17 +0100, kra...@redhat.com wrote:
> On Thu, Jan 06, 2022 at 02:21:59PM +0000, Boeuf, Sebastien wrote:
> > On Wed, 2022-01-05 at 17:55 +0100, kra...@redhat.com wrote:
> > > On Wed, Jan 05, 2022 at 01:44:01PM +, Boeuf, Sebastien wrote:
> > >
I finally got it to work by using the XenTimerDxe. The reason why it
works is because the UEFI service SetTimer() needs one Timer
Architectural Protocol to be installed. In case of standard QEMU, the
8254 PIT is the one registering the service, while for microvm the Xen
timer does the job.
It's in
On Mon, 2022-01-10 at 00:16 +, Xu, Min M wrote:
> On January 7, 2022 9:37 PM, Gerd Hoffmann wrote:
> >
> > > > tianocore doesn't use interrupts (other than timer).
> > >
> > > Yes I realized that by diving into the code. I can see microvm
> > > using
> > > the Xen timer while OvmfPkgX64 uses
Hi all,
So far I've been able to patch the OvmfPkgX64 target to make it work for both
QEMU and Cloud Hypervisor, but as I try to enable more features (EFI shell for
instance) the gap is getting bigger and harder to keep them working together.
That's why I'm thinking about creating an OvmfCh targe
g\Microvm\MicrovmX64.fdf
>
> And we will have OvmfPkg\IntelTdx\IntelTdxX64.fdf soon.
>
> I think it is OK to create:
> OvmfPkg\CloudHv\CloudHvX64.fdf
Sounds good, I'll start working on this.
>
> Thank you
> Yao Jiewen
>
> > -Original Message-
> >
On Mon, 2022-01-10 at 11:45 +0100, kra...@redhat.com wrote:
> On Mon, Jan 10, 2022 at 09:13:44AM +0000, Boeuf, Sebastien wrote:
> > Hi all,
> >
> > So far I've been able to patch the OvmfPkgX64 target to make it
> > work for both
> > QEMU and Cloud Hypervisor
From: Sebastien Boeuf
Since Cloud Hypervisor and QEMU pc/q35 are quite different, it makes
more sense to create a dedicated OVMF target for Cloud Hypervisor rather
than trying to support both VMMs from the same OvmfPkgX64 target.
That's the reason why this series introduces a new target called
C
From: Sebastien Boeuf
Adding the new target CloudHvX64, copied directly from OvmfPkgX64. The
point is to create a target dedicated for Cloud Hypervisor rather than
trying to support both QEMU and Cloud Hypervisor on the same target.
Improvements and cleanups will be performed in follow up patche
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate the legacy 8254 PIT, which is why
instead of relying on it as the timer UEFI services, rely on the
XenTimerDxe implementation. This is not Xen specific, as it simply uses
the local APIC timer triggering interrupts on the vector 32.
Signed-of
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate any LPC bridge, therefore we simply
need to rely on the serial I/O port to be connected as a console.
It reuses the code from Xen since it's very generic.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc
From: Sebastien Boeuf
Cloud Hypervisor does not emulate any 8259 PIC, therefore there's no
reason to load the corresponding driver for it.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 4
OvmfPkg/CloudHv/CloudHvX64.fdf | 1 -
2 files changed, 5 deletions(-)
diff --g
From: Sebastien Boeuf
Anything specific to the QEMU Q35 platform is not relevant for the
CloudHv target.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 10 --
1 file changed, 10 deletions(-)
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.
From: Sebastien Boeuf
Since Cloud Hypervisor doesn't rely on the FwCfg mechanism, remove the
libraries imports when possible.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 2 --
1 file changed, 2 deletions(-)
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/
From: Sebastien Boeuf
No need for video or virtio-gpu support since Cloud Hypervisor doesn't
emulate any of these.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 16
OvmfPkg/CloudHv/CloudHvX64.fdf | 4
2 files changed, 20 deletions(-)
diff --git a/O
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate any USB controller or device, therefore
the support can be removed.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 11 ---
OvmfPkg/CloudHv/CloudHvX64.fdf | 10 --
2 files changed, 21 deletions(-)
diff
From: Sebastien Boeuf
Cloud Hypervisor doesn't need the support for legacy BIOS, therefore the
CSM support can be removed.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 20
OvmfPkg/CloudHv/CloudHvX64.fdf | 6 --
2 files changed, 26 deletions(-)
imilar to below
>
> OvmfPkg: microvm-related modules
> F: OvmfPkg/Microvm/
> F: OvmfPkg/Include/IndustryStandard/Microvm.h
> F: OvmfPkg/Library/ResetSystemLib/*Microvm.*
> R: Gerd Hoffmann [kraxel]
>
Oh yes I'll add this!
Thanks,
Sebastien
>
> > ---
e that's what you suggested :)
Thanks,
Sebastien
>
> Thank you
> Yao Jiewen
>
> > -Original Message-
> > From: Boeuf, Sebastien
> > Sent: Monday, January 10, 2022 10:26 PM
> > To: devel@edk2.groups.io
> > Cc: Yao, Jiewen ; Jus
From: Sebastien Boeuf
Since Cloud Hypervisor and QEMU pc/q35 are quite different, it makes
more sense to create a dedicated OVMF target for Cloud Hypervisor rather
than trying to support both VMMs from the same OvmfPkgX64 target.
That's the reason why this series introduces a new target called
C
From: Sebastien Boeuf
Adding the new target CloudHvX64, copied directly from OvmfPkgX64. The
point is to create a target dedicated for Cloud Hypervisor rather than
trying to support both QEMU and Cloud Hypervisor on the same target.
Improvements and cleanups will be performed in follow up patche
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate the legacy 8254 PIT, which is why
instead of relying on it as the timer UEFI services, rely on the
XenTimerDxe implementation. This is not Xen specific, as it simply uses
the local APIC timer triggering interrupts on the vector 32.
Acked-by:
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate any LPC bridge, therefore we simply
need to rely on the serial I/O port to be connected as a console.
It reuses the code from Xen since it's very generic.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc
From: Sebastien Boeuf
Cloud Hypervisor does not emulate any 8259 PIC, therefore there's no
reason to load the corresponding driver for it.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 4
OvmfPkg/CloudHv/CloudHvX64.fdf | 1 -
2 files changed, 5
From: Sebastien Boeuf
Anything specific to the QEMU Q35 platform is not relevant for the
CloudHv target.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 10 --
1 file changed, 10 deletions(-)
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfP
From: Sebastien Boeuf
Since Cloud Hypervisor doesn't rely on the FwCfg mechanism, remove the
libraries imports when possible.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 2 --
1 file changed, 2 deletions(-)
diff --git a/OvmfPkg/CloudHv/CloudHvX64.
From: Sebastien Boeuf
No need for video or virtio-gpu support since Cloud Hypervisor doesn't
emulate any of these.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 16
OvmfPkg/CloudHv/CloudHvX64.fdf | 4
2 files changed, 20 deleti
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate any USB controller or device, therefore
the support can be removed.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 11 ---
OvmfPkg/CloudHv/CloudHvX64.fdf | 10 --
2 files changed,
From: Sebastien Boeuf
Cloud Hypervisor doesn't need the support for legacy BIOS, therefore the
CSM support can be removed.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 20
OvmfPkg/CloudHv/CloudHvX64.fdf | 6 --
2 files chan
From: Sebastien Boeuf
Signed-off-by: Sebastien Boeuf
---
Maintainers.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Maintainers.txt b/Maintainers.txt
index 71c42bddae..3bda97ef25 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -440,6 +440,11 @@ F:
OvmfPkg/Library/ResetSyste
From: Sebastien Boeuf
Adding the new target CloudHvX64, copied directly from OvmfPkgX64. The
point is to create a target dedicated for Cloud Hypervisor rather than
trying to support both QEMU and Cloud Hypervisor on the same target.
Improvements and cleanups will be performed in follow up patche
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate the legacy 8254 PIT, which is why
instead of relying on it as the timer UEFI services, rely on the
XenTimerDxe implementation. This is not Xen specific, as it simply uses
the local APIC timer triggering interrupts on the vector 32.
Acked-by:
From: Sebastien Boeuf
Since Cloud Hypervisor and QEMU pc/q35 are quite different, it makes
more sense to create a dedicated OVMF target for Cloud Hypervisor rather
than trying to support both VMMs from the same OvmfPkgX64 target.
That's the reason why this series introduces a new target called
C
From: Sebastien Boeuf
Cloud Hypervisor does not emulate any 8259 PIC, therefore there's no
reason to load the corresponding driver for it.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 4
OvmfPkg/CloudHv/CloudHvX64.fdf | 1 -
2 files changed, 5
From: Sebastien Boeuf
Since Cloud Hypervisor doesn't rely on the FwCfg mechanism, remove the
libraries imports when possible.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 2 --
1 file changed, 2 deletions(-)
diff --git a/OvmfPkg/CloudHv/CloudHvX64.
From: Sebastien Boeuf
Anything specific to the QEMU Q35 platform is not relevant for the
CloudHv target.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 10 --
1 file changed, 10 deletions(-)
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfP
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate any LPC bridge, therefore we simply
need to rely on the serial I/O port to be connected as a console.
It reuses the code from Xen since it's very generic.
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc
From: Sebastien Boeuf
No need for video or virtio-gpu support since Cloud Hypervisor doesn't
emulate any of these.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 16
OvmfPkg/CloudHv/CloudHvX64.fdf | 4
2 files changed, 20 deleti
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate any USB controller or device, therefore
the support can be removed.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 11 ---
OvmfPkg/CloudHv/CloudHvX64.fdf | 10 --
2 files changed,
From: Sebastien Boeuf
Cloud Hypervisor doesn't need the support for legacy BIOS, therefore the
CSM support can be removed.
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 20
OvmfPkg/CloudHv/CloudHvX64.fdf | 6 --
2 files chan
From: Sebastien Boeuf
Signed-off-by: Sebastien Boeuf
---
Maintainers.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Maintainers.txt b/Maintainers.txt
index 71c42bddae..3bda97ef25 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -440,6 +440,11 @@ F:
OvmfPkg/Library/ResetSyste
From: Sebastien Boeuf
Adding the newly created target for Cloud Hypervisor to the CI,
validating it can be properly built.
Signed-off-by: Sebastien Boeuf
---
.../.azurepipelines/Ubuntu-GCC5.yml | 9 +
OvmfPkg/PlatformCI/CloudHvBuild.py| 37 +++
2 file
From: Sebastien Boeuf
Since Cloud Hypervisor and QEMU pc/q35 are quite different, it makes
more sense to create a dedicated OVMF target for Cloud Hypervisor rather
than trying to support both VMMs from the same OvmfPkgX64 target.
That's the reason why this series introduces a new target called
C
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate the legacy 8254 PIT, which is why
instead of relying on it as the timer UEFI services, rely on the
XenTimerDxe implementation. This is not Xen specific, as it simply uses
the local APIC timer triggering interrupts on the vector 32.
Acked-by:
From: Sebastien Boeuf
Adding the new target CloudHvX64, copied directly from OvmfPkgX64. The
point is to create a target dedicated for Cloud Hypervisor rather than
trying to support both QEMU and Cloud Hypervisor on the same target.
Improvements and cleanups will be performed in follow up patche
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate any LPC bridge, therefore we simply
need to rely on the serial I/O port to be connected as a console.
It reuses the code from Xen since it's very generic.
Acked-by: Gerd Hoffmann
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
Ov
From: Sebastien Boeuf
Cloud Hypervisor does not emulate any 8259 PIC, therefore there's no
reason to load the corresponding driver for it.
Acked-by: Gerd Hoffmann
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 4
OvmfPkg/CloudHv/CloudHvX64.fdf |
From: Sebastien Boeuf
Anything specific to the QEMU Q35 platform is not relevant for the
CloudHv target.
Acked-by: Gerd Hoffmann
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 10 --
1 file changed, 10 deletions(-)
diff --git a/OvmfPkg/Cloud
From: Sebastien Boeuf
Since Cloud Hypervisor doesn't rely on the FwCfg mechanism, remove the
libraries imports when possible.
Acked-by: Gerd Hoffmann
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 2 --
1 file changed, 2 deletions(-)
diff --git a/Ov
From: Sebastien Boeuf
No need for video or virtio-gpu support since Cloud Hypervisor doesn't
emulate any of these.
Acked-by: Gerd Hoffmann
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 16
OvmfPkg/CloudHv/CloudHvX64.fdf | 4
2
From: Sebastien Boeuf
Cloud Hypervisor doesn't emulate any USB controller or device, therefore
the support can be removed.
Acked-by: Gerd Hoffmann
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 11 ---
OvmfPkg/CloudHv/CloudHvX64.fdf | 10
From: Sebastien Boeuf
Acked-by: Gerd Hoffmann
Reviewed-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
Maintainers.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Maintainers.txt b/Maintainers.txt
index 71c42bddae..3bda97ef25 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@
From: Sebastien Boeuf
Cloud Hypervisor doesn't need the support for legacy BIOS, therefore the
CSM support can be removed.
Acked-by: Gerd Hoffmann
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
OvmfPkg/CloudHv/CloudHvX64.dsc | 20
OvmfPkg/CloudHv/CloudHvX64.fdf
From: Sebastien Boeuf
Adding the newly created target for Cloud Hypervisor to the CI,
validating it can be properly built.
Acked-by: Gerd Hoffmann
Acked-by: Jiewen Yao
Signed-off-by: Sebastien Boeuf
---
.../.azurepipelines/Ubuntu-GCC5.yml | 9 +
OvmfPkg/PlatformCI/CloudHvBuild
at 13:17 +0100, kra...@redhat.com wrote:
> On Thu, Jan 06, 2022 at 02:21:59PM +0000, Boeuf, Sebastien wrote:
> > On Wed, 2022-01-05 at 17:55 +0100, kra...@redhat.com wrote:
> > > On Wed, Jan 05, 2022 at 01:44:01PM +, Boeuf, Sebastien wrote:
> > > > Ah nevermind
Hi,
I was thinking about running a simple test with Cloud Hypervisor (VMM
relying on KVM) to validate the associated Ovmf target can be properly
booted. Unfortunately I get an error about /dev/kvm not being
available.
Is there a way to let the Azure Pipelines know that we need a machine
that supp
Great, thank you!
Sebastien
From: Yao, Jiewen
Sent: Thursday, January 13, 2022 3:56:09 PM
To: Boeuf, Sebastien ; devel@edk2.groups.io
Cc: Justen, Jordan L ; kra...@redhat.com
Subject: RE: [PATCH v4 00/11] Create new target for Cloud Hypervisor
Merged: https
Any idea?
From: devel@edk2.groups.io on behalf of Boeuf, Sebastien
Sent: Tuesday, January 11, 2022 4:23 PM
To: Kinney, Michael D ; bret.barke...@microsoft.com
; sean.bro...@microsoft.com
; devel@edk2.groups.io
Subject: [edk2-devel] Does CI support nested
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 (3):
OvmfPkg: Generate CloudHv as a PVH ELF binary
OvmfPkg: CloudHv: Retrieve RSDP address from PVH
OvmfPkg: Cl
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/CloudHvElfHeaderGenerator.c | 150
OvmfPkg/CloudHv/CloudHvX64.dsc
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
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
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
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
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
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
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
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
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
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
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
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 +-
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
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
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
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
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
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 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
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
1 - 100 of 178 matches
Mail list logo
