From nobody Tue Feb 10 02:43:09 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1644412240900595.2043158773363; Wed, 9 Feb 2022 05:10:40 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.269118.463128 (Exim 4.92) (envelope-from ) id 1nHmjl-00046L-Pu; Wed, 09 Feb 2022 13:10:21 +0000 Received: by outflank-mailman (output) from mailman id 269118.463128; Wed, 09 Feb 2022 13:10:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1nHmjl-00046A-LG; Wed, 09 Feb 2022 13:10:21 +0000 Received: by outflank-mailman (input) for mailman id 269118; Wed, 09 Feb 2022 13:10:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1nHmjk-0003YU-He for xen-devel@lists.xenproject.org; Wed, 09 Feb 2022 13:10:20 +0000 Received: from smtp1.irit.fr (smtp1.irit.fr [141.115.24.2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a18889dd-89a9-11ec-8f75-fffcc8bd4f1a; Wed, 09 Feb 2022 14:10:19 +0100 (CET) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a18889dd-89a9-11ec-8f75-fffcc8bd4f1a From: Tu Dinh Ngoc To: xen-devel@lists.xenproject.org Cc: Tu Dinh Ngoc Subject: [PATCH 2/2] x86: Set up framebuffer given by Multiboot2 Date: Wed, 9 Feb 2022 14:09:07 +0100 Message-Id: <20220209130907.252-3-dinhngoc.tu@irit.fr> In-Reply-To: <20220209130907.252-1-dinhngoc.tu@irit.fr> References: <20220209130907.252-1-dinhngoc.tu@irit.fr> Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1644412242167100002 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Previously, we do not make use of the framebuffer given by Multiboot. This means graphics will not work in some scenarios such as booting from Kexec. Enable the Multiboot framebuffer if it exists and not overridden by EFI probe. --- xen/arch/x86/setup.c | 45 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 42 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 115f8f6517..04d8be407e 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -551,16 +551,55 @@ struct boot_video_info { extern struct boot_video_info boot_vid_info; #endif =20 -static void __init parse_video_info(void) +static void __init parse_video_info(multiboot_info_t *mbi) { #ifdef CONFIG_VIDEO struct boot_video_info *bvi =3D &bootsym(boot_vid_info); =20 + /* + * fb detection will be in this order: + * - efifb (as efifb probe sets a new GOP mode before parse_video_inf= o is called, + * we must use this mode instead of the one given by mbifb) + * - mbifb + * - vesafb + */ + /* vga_console_info is filled directly on EFI platform. */ if ( efi_enabled(EFI_BOOT) ) return; =20 - if ( (bvi->orig_video_isVGA =3D=3D 1) && (bvi->orig_video_mode =3D=3D = 3) ) + if ( mbi->flags & MBI_FB ) + { + uint64_t lfb_rgb_bitmap =3D 0; + + vga_console_info.video_type =3D XEN_VGATYPE_VESA_LFB; + vga_console_info.u.vesa_lfb.width =3D mbi->fb.width; + vga_console_info.u.vesa_lfb.height =3D mbi->fb.height; + vga_console_info.u.vesa_lfb.bytes_per_line =3D mbi->fb.pitch; + vga_console_info.u.vesa_lfb.bits_per_pixel =3D mbi->fb.bpp; + vga_console_info.u.vesa_lfb.lfb_base =3D mbi->fb.addr; + vga_console_info.u.vesa_lfb.lfb_size =3D (mbi->fb.pitch * mbi->fb.= height + 0xffff) >> 16; + + vga_console_info.u.vesa_lfb.red_pos =3D mbi->fb.red_pos; + vga_console_info.u.vesa_lfb.red_size =3D mbi->fb.red_size; + lfb_rgb_bitmap |=3D (((uint64_t)1 << mbi->fb.red_size) - 1) << mbi= ->fb.red_pos; + vga_console_info.u.vesa_lfb.green_pos =3D mbi->fb.green_pos; + vga_console_info.u.vesa_lfb.green_size =3D mbi->fb.green_size; + lfb_rgb_bitmap |=3D (((uint64_t)1 << mbi->fb.green_size) - 1) << m= bi->fb.green_pos; + vga_console_info.u.vesa_lfb.blue_pos =3D mbi->fb.blue_pos; + vga_console_info.u.vesa_lfb.blue_size =3D mbi->fb.blue_size; + lfb_rgb_bitmap |=3D (((uint64_t)1 << mbi->fb.blue_size) - 1) << mb= i->fb.blue_pos; + + /* assume non-weird bit format */ + vga_console_info.u.vesa_lfb.rsvd_pos =3D find_first_zero_bit(&lfb_= rgb_bitmap, sizeof(lfb_rgb_bitmap) * __CHAR_BIT__); + vga_console_info.u.vesa_lfb.rsvd_size =3D mbi->fb.bpp - mbi->fb.re= d_size - mbi->fb.green_size - mbi->fb.blue_size; + if (vga_console_info.u.vesa_lfb.rsvd_pos >=3D mbi->fb.bpp || vga_c= onsole_info.u.vesa_lfb.rsvd_size < 0) { + vga_console_info.u.vesa_lfb.rsvd_pos =3D 0; + vga_console_info.u.vesa_lfb.rsvd_size =3D 0; + } + vga_console_info.u.vesa_lfb.gbl_caps =3D 2; /* possibly non-VGA */ + } + else if ( (bvi->orig_video_isVGA =3D=3D 1) && (bvi->orig_video_mode = =3D=3D 3) ) { vga_console_info.video_type =3D XEN_VGATYPE_TEXT_MODE_3; vga_console_info.u.text_mode_3.font_height =3D bvi->orig_video_poi= nts; @@ -933,7 +972,7 @@ void __init noreturn __start_xen(unsigned long mbi_p) */ hypervisor_name =3D hypervisor_probe(); =20 - parse_video_info(); + parse_video_info(mbi); =20 rdmsrl(MSR_EFER, this_cpu(efer)); asm volatile ( "mov %%cr4,%0" : "=3Dr" (get_cpu_info()->cr4) ); --=20 2.25.1