Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB

From: Marek Marczykowski <marmarek@invisiblethingslab.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Julien Grall <julien.grall@arm.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
Date: Tue, 7 May 2019 17:38:25 +0200	[thread overview]
Message-ID: <20190507153825.GA1502@mail-itl> (raw)
In-Reply-To: <5CD14B6E020000780022C646@prv1-mh.provo.novell.com>

[-- Attachment #1.1: Type: text/plain, Size: 2149 bytes --]

On Tue, May 07, 2019 at 03:10:06AM -0600, Jan Beulich wrote:
> >>> On 06.05.19 at 17:32, <marmarek@invisiblethingslab.com> wrote:
> > On Mon, May 06, 2019 at 05:15:19PM +0200, Juergen Gross wrote:
> >> On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote:
> >> > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> >> > index ccdffc0..b0f0f7e 100644
> >> > --- a/xen/include/public/xen.h
> >> > +++ b/xen/include/public/xen.h
> >> > @@ -923,6 +923,8 @@ typedef struct dom0_vga_console_info {
> >> >              /* Mode attributes (offset 0x0, VESA command 0x4f01). */
> >> >              uint16_t mode_attrs;
> >> >  #endif
> >> > +            /* high 32 bits of lfb_base */
> >> > +            uint32_t ext_lfb_base;
> >> 
> >> You will need to put this addition into an:
> >> 
> >> #if __XEN_INTERFACE_VERSION__ >= 0x00040d00
> >> ...
> >> #endif
> >> 
> >> section (only available from Xen 4.13 onwards).
> > 
> > Why exactly? I don't see this structure used in any hypercall argument.
> > The only externally accessible place is start_info structure, where it
> > has explicit struct size already.
> 
> In addition to Jürgen's reply: While the structure isn't meant to
> be used that way, any consumer of the Xen headers could in
> principle create instances of it (rather than just using pointers
> to the Xen-provided instance), and without the consuming code
> signaling its awareness such structure sizes may not change.

Ok.

What do you think about adding something that could be backported?
Xen is quite insistent on initializing framebuffer, even with
console=com1 or console=none. Which means, there is no workaround for
this problem.

Maybe, as a first step, a change that abort framebuffer initialization
if lfb_base == 0 (I assume this is never valid value here, right?)?
If not, then at least abort boot when text console is still there
(blexit before efi_exit_boot). Any preference?

-- 
Best Regards,
Marek Marczykowski-Górecki
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?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel