From patchwork Thu Mar 28 17:40:06 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Anthony PERARD X-Patchwork-Id: 10875581 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id BBB5B1575 for ; Thu, 28 Mar 2019 17:42:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A0CF228CC4 for ; Thu, 28 Mar 2019 17:42:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9EF4628ED4; Thu, 28 Mar 2019 17:42:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 471DB28EB3 for ; Thu, 28 Mar 2019 17:42:02 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1h9Z0g-0001cZ-LG; Thu, 28 Mar 2019 17:40:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1h9Z0f-0001cT-L3 for xen-devel@lists.xenproject.org; Thu, 28 Mar 2019 17:40:13 +0000 X-Inumbo-ID: 88969ed0-5180-11e9-9a02-73ce9fe0ac20 Received: from SMTP03.CITRIX.COM (unknown [162.221.156.55]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 88969ed0-5180-11e9-9a02-73ce9fe0ac20; Thu, 28 Mar 2019 17:40:10 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.60,281,1549929600"; d="scan'208";a="82124156" Date: Thu, 28 Mar 2019 17:40:06 +0000 From: Anthony PERARD To: Boris Ostrovsky , Juergen Gross Message-ID: <20190328174006.GH1420@perard.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) Subject: [Xen-devel] Boot Linux on PVH guest via OVMF/UEFI issues X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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, 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; }