From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Marczykowski Subject: Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB Date: Thu, 9 May 2019 02:22:39 +0200 Message-ID: <20190509002239.GD24075@mail-itl> References: <5CD14ACF020000780022C643@prv1-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1315688432485235332==" Return-path: 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 1hOWpl-0005Xc-4L for xen-devel@lists.xenproject.org; Thu, 09 May 2019 00:22:49 +0000 In-Reply-To: <5CD14ACF020000780022C643@prv1-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" To: Jan Beulich Cc: Stefano Stabellini , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , Tim Deegan , Julien Grall , xen-devel , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org --===============1315688432485235332== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eheScQNz3K90DVRs" Content-Disposition: inline --eheScQNz3K90DVRs Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 07, 2019 at 03:07:27AM -0600, Jan Beulich wrote: > >>> On 06.05.19 at 16:50, wrote: > > --- a/xen/drivers/video/vesa.c > > +++ b/xen/drivers/video/vesa.c > > @@ -84,6 +84,7 @@ void __init vesa_early_init(void) > > void __init vesa_init(void) > > { > > struct lfb_prop lfbp; > > + unsigned long lfb_base; > > =20 > > if ( !font ) > > return; > > @@ -97,15 +98,17 @@ void __init vesa_init(void) > > lfbp.text_columns =3D vlfb_info.width / font->width; > > lfbp.text_rows =3D vlfb_info.height / font->height; > > =20 > > - lfbp.lfb =3D lfb =3D ioremap(vlfb_info.lfb_base, vram_remap); > > + lfb_base =3D vlfb_info.lfb_base; > > + lfb_base |=3D (unsigned long)vlfb_info.ext_lfb_base << 32; > > + lfbp.lfb =3D lfb =3D ioremap(lfb_base, vram_remap); > > if ( !lfb ) > > return; > > =20 > > memset(lfb, 0, vram_remap); > > =20 > > - printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, " > > + printk(XENLOG_INFO "vesafb: framebuffer at %#lx, mapped to 0x%p, " > > "using %uk, total %uk\n", > > - vlfb_info.lfb_base, lfb, > > + lfb_base, lfb, > > vram_remap >> 10, vram_total >> 10); > > printk(XENLOG_INFO "vesafb: mode is %dx%dx%u, linelength=3D%d, fon= t %ux%u\n", > > vlfb_info.width, vlfb_info.height, > > @@ -152,6 +155,10 @@ void __init vesa_mtrr_init(void) > > MTRR_TYPE_WRCOMB, MTRR_TYPE_WRTHROUGH }; > > unsigned int size_total; > > int rc, type; > > + unsigned long lfb_base; > > + > > + lfb_base =3D vlfb_info.lfb_base; > > + lfb_base |=3D (unsigned long)vlfb_info.ext_lfb_base << 32; > > =20 > > if ( !lfb || (vesa_mtrr =3D=3D 0) || (vesa_mtrr >=3D ARRAY_SIZE(mt= rr_types)) ) > > return; > > @@ -167,7 +174,7 @@ void __init vesa_mtrr_init(void) > > =20 > > /* Try and find a power of two to add */ > > do { > > - rc =3D mtrr_add(vlfb_info.lfb_base, size_total, type, 1); > > + rc =3D mtrr_add(lfb_base, size_total, type, 1); > > size_total >>=3D 1; > > } while ( (size_total >=3D PAGE_SIZE) && (rc =3D=3D -EINVAL) ); > > } >=20 > Imo the result would be better readable if, instead of the local > variables, you introduced an inline helper lfb_base(). Not necessarily - vlfb_info is a #define to vga_console_info.u.vesa_lfb. This means such helper would either not have any parameters, or would need to have full struct xen_console_info as a parameter (inner structure is anonymous). In both cases, it won't be obvious that lfb_base live inside vlfb_info. I could add yet another #define instead of inline function for that, but it wouldn't avoid the second (minor) issue: a helper without a variable would mean reading the value twice in vesa_init(). In theory it shouldn't change in the meantime, but IMO better avoid it anyway. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --eheScQNz3K90DVRs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlzTcs8ACgkQ24/THMrX 1ywypgf9FnNpig05C6LReZHSLjSgz2S0mYHEhz9ki0UedKlFSQ+KIa0RcBG4erXr OgevlkeZ5tRrzlRybApQoleZrGSaoe0rNN0go0K4sbKbVLnrjnqjovS9mdRsTEPQ Izgqq9kq5dLjvOC5JatPGCO4vvX6wrvHjk0J09bC13OJxWnXqtI2bGhx683qH1ue oH3htvWaI33YKtgxeii3HT8rlzQyX4jlXyTHig2QQFE2N+TVbisyobHJJ0/qpFr0 RRd9FiUb7AlEwaP9mG7cWZbAXsbFqOQw01NcXI8T99uYaJz9glcTqncFDGMwhhaS XMREBvUva1ntzca77/HIOrVBrlyUKA== =TwOw -----END PGP SIGNATURE----- --eheScQNz3K90DVRs-- --===============1315688432485235332== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============1315688432485235332==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4635C04A6B for ; Thu, 9 May 2019 00:23:22 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8DA7A216C4 for ; Thu, 9 May 2019 00:23:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="ZA2yjVFA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8DA7A216C4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=invisiblethingslab.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hOWpm-0005Xh-O5; Thu, 09 May 2019 00:22:50 +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 1hOWpl-0005Xc-4L for xen-devel@lists.xenproject.org; Thu, 09 May 2019 00:22:49 +0000 X-Inumbo-ID: 90e4c914-71f0-11e9-87f6-fb00d9f2f82b Received: from new3-smtp.messagingengine.com (unknown [66.111.4.229]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 90e4c914-71f0-11e9-87f6-fb00d9f2f82b; Thu, 09 May 2019 00:22:45 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id A1E9314DA0; Wed, 8 May 2019 20:22:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 08 May 2019 20:22:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=qPh3dm 3kmVwR28pXZyy8rFEN+NMNoWJVgY4kjmhKzKw=; b=ZA2yjVFAXmjlPylIi2pmUu MDBFHIbaTKMlpK4rFbjmJIL+B8Kl5CGIVzmSqQcxpJaqyTOTdHl0EASg2h/JKwHo w2o8dLBcAs8EuQwN8RInaCdUl72Jq0HTSgST6lUpIEde5YcAVM72oY1Lioo8PZSX T66ZpKcJgCWRzQXGfMJX6iZTm2lesF3Kxd7PSNGhu4Gzjrw/qiEjnJC1aBDp4YSX dPdv6AL8kFLeSLFfCC8fhYAuZ17kCoDT+9trqxPbC0hsvYIvQDs7/xtd+Q5dOenC AMhXrKxMryquIEIVfhwyFceJHTtysi4wurynL5KOTERlVHjN71dCvUZV6kHbre0g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkeeggdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujggfsehgtderredtreejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthh hinhhgshhlrggsrdgtohhmqeenucfkphepledurdeihedrfeegrdeffeenucfrrghrrghm pehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslh grsgdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 5A93A80060; Wed, 8 May 2019 20:22:42 -0400 (EDT) Date: Thu, 9 May 2019 02:22:39 +0200 From: Marek Marczykowski To: Jan Beulich Message-ID: <20190509002239.GD24075@mail-itl> References: <5CD14ACF020000780022C643@prv1-mh.provo.novell.com> MIME-Version: 1.0 In-Reply-To: <5CD14ACF020000780022C643@prv1-mh.provo.novell.com> User-Agent: Mutt/1.11.1+94 (9b965fac) (2019-01-05) Subject: Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB 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: Stefano Stabellini , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , Tim Deegan , Julien Grall , xen-devel , Roger Pau Monne Content-Type: multipart/mixed; boundary="===============1315688432485235332==" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Message-ID: <20190509002239.ZcNWBnitYPiprFyhdh77FquTGVuxBUQzX0XlbBHC2Xo@z> --===============1315688432485235332== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eheScQNz3K90DVRs" Content-Disposition: inline --eheScQNz3K90DVRs Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 07, 2019 at 03:07:27AM -0600, Jan Beulich wrote: > >>> On 06.05.19 at 16:50, wrote: > > --- a/xen/drivers/video/vesa.c > > +++ b/xen/drivers/video/vesa.c > > @@ -84,6 +84,7 @@ void __init vesa_early_init(void) > > void __init vesa_init(void) > > { > > struct lfb_prop lfbp; > > + unsigned long lfb_base; > > =20 > > if ( !font ) > > return; > > @@ -97,15 +98,17 @@ void __init vesa_init(void) > > lfbp.text_columns =3D vlfb_info.width / font->width; > > lfbp.text_rows =3D vlfb_info.height / font->height; > > =20 > > - lfbp.lfb =3D lfb =3D ioremap(vlfb_info.lfb_base, vram_remap); > > + lfb_base =3D vlfb_info.lfb_base; > > + lfb_base |=3D (unsigned long)vlfb_info.ext_lfb_base << 32; > > + lfbp.lfb =3D lfb =3D ioremap(lfb_base, vram_remap); > > if ( !lfb ) > > return; > > =20 > > memset(lfb, 0, vram_remap); > > =20 > > - printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, " > > + printk(XENLOG_INFO "vesafb: framebuffer at %#lx, mapped to 0x%p, " > > "using %uk, total %uk\n", > > - vlfb_info.lfb_base, lfb, > > + lfb_base, lfb, > > vram_remap >> 10, vram_total >> 10); > > printk(XENLOG_INFO "vesafb: mode is %dx%dx%u, linelength=3D%d, fon= t %ux%u\n", > > vlfb_info.width, vlfb_info.height, > > @@ -152,6 +155,10 @@ void __init vesa_mtrr_init(void) > > MTRR_TYPE_WRCOMB, MTRR_TYPE_WRTHROUGH }; > > unsigned int size_total; > > int rc, type; > > + unsigned long lfb_base; > > + > > + lfb_base =3D vlfb_info.lfb_base; > > + lfb_base |=3D (unsigned long)vlfb_info.ext_lfb_base << 32; > > =20 > > if ( !lfb || (vesa_mtrr =3D=3D 0) || (vesa_mtrr >=3D ARRAY_SIZE(mt= rr_types)) ) > > return; > > @@ -167,7 +174,7 @@ void __init vesa_mtrr_init(void) > > =20 > > /* Try and find a power of two to add */ > > do { > > - rc =3D mtrr_add(vlfb_info.lfb_base, size_total, type, 1); > > + rc =3D mtrr_add(lfb_base, size_total, type, 1); > > size_total >>=3D 1; > > } while ( (size_total >=3D PAGE_SIZE) && (rc =3D=3D -EINVAL) ); > > } >=20 > Imo the result would be better readable if, instead of the local > variables, you introduced an inline helper lfb_base(). Not necessarily - vlfb_info is a #define to vga_console_info.u.vesa_lfb. This means such helper would either not have any parameters, or would need to have full struct xen_console_info as a parameter (inner structure is anonymous). In both cases, it won't be obvious that lfb_base live inside vlfb_info. I could add yet another #define instead of inline function for that, but it wouldn't avoid the second (minor) issue: a helper without a variable would mean reading the value twice in vesa_init(). In theory it shouldn't change in the meantime, but IMO better avoid it anyway. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --eheScQNz3K90DVRs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlzTcs8ACgkQ24/THMrX 1ywypgf9FnNpig05C6LReZHSLjSgz2S0mYHEhz9ki0UedKlFSQ+KIa0RcBG4erXr OgevlkeZ5tRrzlRybApQoleZrGSaoe0rNN0go0K4sbKbVLnrjnqjovS9mdRsTEPQ Izgqq9kq5dLjvOC5JatPGCO4vvX6wrvHjk0J09bC13OJxWnXqtI2bGhx683qH1ue oH3htvWaI33YKtgxeii3HT8rlzQyX4jlXyTHig2QQFE2N+TVbisyobHJJ0/qpFr0 RRd9FiUb7AlEwaP9mG7cWZbAXsbFqOQw01NcXI8T99uYaJz9glcTqncFDGMwhhaS XMREBvUva1ntzca77/HIOrVBrlyUKA== =TwOw -----END PGP SIGNATURE----- --eheScQNz3K90DVRs-- --===============1315688432485235332== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============1315688432485235332==--