Boot Linux on PVH guest via OVMF/UEFI issues

Commit Message

Anthony PERARD March 28, 2019, 5:40 p.m. UTC

Hi,

I've been working on adding PVH support to OVMF and boot Linux with it.
The last issue I had was a guest crash without any error messages.
Tests done with Linux 4.20.12-arch1-1-ARCH.

In this mail, I'll discuss about two issues:
- Linux oops/panic but don't print anything in the console.
- Linux requires a VGA region or crash.

# About the guest crash without error messages

I had a guest crash just after systemd started to print messages on the
console. But neither Linux nor Xen had printed anything about why the
guest crash. No amount of command line options helped.

I've managed to have Linux print the error message on panic, but I had
to make a modification so that Linux would not tell Xen when a crash
happened. This patch:
Is it possible in the future for the kernel to actually write panic
message before Xen destroy the domain?


# PVH & EFI & VGA regions.

The issue I had was when systemd was trying to start the virtual
console. In Linux, one of visual_init/vc_allocate was called and it
would crash because the pointer `conswitchp` was NULL or never
initialized properly.

The issue is here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/kernel/setup.c?h=v4.20.17#n1259
'conswitchp' is only set conditionally on EFI based on the type of
memory at the VGA region. So if OVMF says that it's just RAM, then Linux
crash. 

So should I lie about the memory layout and tell the kernel that there
is no RAM around the VGA region?
Or is maybe Linux can be changed and allow it to use that region as RAM?
(And set conswitchp=&dummy_con when the VGA region is absent.)

That might be related to what's done when Linux is booted via the PVH
entry point, here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/xen/enlighten_pvh.c?h=v4.20.17#n51
Do you know why that ISA region (VGA + other bits) is marked as
reserved?

Thanks,

Comments

Jan Beulich March 29, 2019, 11:24 a.m. UTC | #1

>>> On 28.03.19 at 18:40, <[e-mail]> wrote:
> # About the guest crash without error messages
> 
> I had a guest crash just after systemd started to print messages on the
> console. But neither Linux nor Xen had printed anything about why the
> guest crash. No amount of command line options helped.
> 
> I've managed to have Linux print the error message on panic, but I had
> to make a modification so that Linux would not tell Xen when a crash
> happened. This patch:
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -277,8 +277,6 @@ void xen_emergency_restart(void)
>  static int
>  xen_panic_event(struct notifier_block *this, unsigned long event, void *ptr)
>  {
> -       if (!kexec_crash_loaded())
> -               xen_reboot(SHUTDOWN_crash);
>         return NOTIFY_DONE;
>  }
> 
> Is it possible in the future for the kernel to actually write panic
> message before Xen destroy the domain?

Just the day before yesterday I've run into a (deliberately)
panic()-ing DomU, and it _did_ log the panic output. So it's
likely not as simple as a boolean does / doesn't log messages?
Of course in my case it was a PV DomU, and started with -c
rather than the possibly more common -V, which may already
account for the difference. I.e. I wonder whether there's
too much of a delay for the output to actually make it out in
some cases. And if so, it might not even be the kernel's
"fault".

Jan

Patch

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -277,8 +277,6 @@  void xen_emergency_restart(void)
 static int
 xen_panic_event(struct notifier_block *this, unsigned long event, void *ptr)
 {
-       if (!kexec_crash_loaded())
-               xen_reboot(SHUTDOWN_crash);
        return NOTIFY_DONE;
 }