On Thu, Oct 05, 2023 at 09:54:26AM +0100, Julien Grall wrote:
> On 04/10/2023 22:13, Elliott Mitchell wrote:
> >>> I understand the situation is different on Arm vs x86, so if
> >>> edk2 is not supported on arm I guess it doesn't matter much whether
> >>> it's broken. It would be a much worse issue on x86 where edk2 is
> >>> supported.
> >>
> >> AFAIK, we have CI for x86 on EDK2 but we don't on Arm.
> >
> > What is the current status of this? I'm unsure whether it was an extra
> > patch done by Debian, but "edk2-stable202211"/fff6d81270 doesn't work
> > with Xen/Qemu.
>
> I don't know what's the status for x86. But for Arm, there are nothing.
> And as I pointed out in my previous answer this is unlikely to change
> until someone invest time in EDK2 on Xen on Arm.
Indications are the measures for x86 aren't very good either. Presently
the Debian distribution is using builds based on tag edk2-stable202211,
commit fff6d81270. Could be the Debian package process got broken.
Could also be that tag, builds are completing yet the output fails to
function.
I've also been trying to get Tianocore/EDK2 to function as a bootloader
for PVH. Current OVMF builds are accepted for the 'kernel = "OVMF.fd"'
line, but simply hang. I'm wondering whether it is assuming the presence
of a framebuffer and doesn't use the x86 Xen console.
> If there are patches sent on the ML, then I am happy to attempt to
> review them. But I am afraid, I am not going to have time to try to find
> and fix all the issues when using EDK2 in Arm guests.
The attached patch got booting via Tianocore/EDK2 working. This likely
needs adjustment to match their style; problem is their style is so
awful I was looking for an airsickness bag. I really don't want to do
further polishing.
I'm unsure whether XENMEM_remove_from_physmap uncovers a memory page
which had been previously mapped, versus turning it into a hole. In
the former case, the allocation should be moved to a normal heap page
since the OS can reuse it.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | ehem+sig...@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
>From 19b0e88b5e0d6954a924f444b02bcb576a115952 Mon Sep 17 00:00:00 2001
Message-Id: <19b0e88b5e0d6954a924f444b02bcb576a115952.1696517822.git.ehem+...@m5p.com>
From: Elliott Mitchell <ehem+...@m5p.com>
Date: Wed, 4 Oct 2023 21:47:17 -0700
Subject: [PATCH] OvmfPkg/XenBusDxe: Unmap shared information page on exit
Xen/ARM now requires the shared information page to only be mapped once.
This behavior is expected to be copied to Xen/x86 at some future point.
Signed-off-by: Elliott Mitchell <ehem+...@m5p.com>
---
OvmfPkg/XenBusDxe/XenBusDxe.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.c b/OvmfPkg/XenBusDxe/XenBusDxe.c
index 132f43a72b..117a299d10 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.c
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.c
@@ -84,6 +84,33 @@ XenGetSharedInfoPage (
return EFI_SUCCESS;
}
+/**
+ Unmap the shared_info_t page from memory.
+
+ @param Dev A XENBUS_DEVICE instance.
+**/
+VOID
+XenClearSharedInfoPage (
+ IN OUT XENBUS_DEVICE *Dev
+ )
+{
+ xen_remove_from_physmap_t Parameter;
+
+ //
+ // Either never mapped, or else already cleared. No further cleanup
+ // action required.
+ //
+ if (!Dev->SharedInfo) return;
+
+ Parameter.domid = DOMID_SELF;
+ Parameter.gpfn = (UINTN)Dev->SharedInfo >> EFI_PAGE_SHIFT;
+ if (XenHypercallMemoryOp (XENMEM_remove_from_physmap, &Parameter) != 0)
+ return;
+
+ FreePages (Dev->SharedInfo, 1);
+ Dev->SharedInfo = NULL;
+}
+
/**
Unloads an image.
@@ -501,6 +528,8 @@ XenBusDxeDriverBindingStop (
XenStoreDeinit (Dev);
XenGrantTableDeinit (Dev);
+ XenClearSharedInfoPage(Dev);
+
gBS->CloseProtocol (
ControllerHandle,
&gEfiDevicePathProtocolGuid,
--
2.39.2
