On Fri, Jan 20, 2023 at 11:33:19AM +0000, David Woodhouse wrote:
From: David Woodhouse dwmw@amazon.co.uk
When running under Xen, hvmloader places a table at 0x1000 with the e820 information and BIOS tables. If this isn't present, SeaBIOS will currently panic.
We now have support for running Xen guests natively in QEMU/KVM, which boots SeaBIOS directly instead of via hvmloader, and does not provide the same structure.
As it happens, this doesn't matter on first boot. because although we set PlatformRunningOn to PF_QEMU|PF_XEN, reading it back again still gives zero. Presumably because in true Xen, this is all already RAM. But in QEMU with a faithfully-emulated PAM config in the host bridge, it's still in ROM mode at this point so we don't see what we've just written.
On reboot, however, the region *is* set to RAM mode and we do see the updated value of PlatformRunningOn, do manage to remember that we've detected Xen in CPUID, and hit the panic.
It's not trivial to detect QEMU vs. real Xen at the time xen_preinit() runs, because it's so early. We can't even make a XENVER_extraversion hypercall to look for hints, because we haven't set up the hypercall page (and don't have an allocator to give us a page in which to do so).
So just make Xen detection contingent on the info structure being present. If it wasn't, we were going to panic anyway. That leaves us taking the standard QEMU init path for Xen guests in native QEMU, which is just fine.
Untested on actual Xen but ObviouslyCorrect™.
Thanks. I don't have a way to test this, but it looks fine to me. I'll give a few more days to see if others have comments, and otherwise look to commit.
Cheers, -Kevin