[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] {xen, dom0}_vga_console_info.u.vesa_lfb.lfb_base field too small
On Mon, May 06, 2019 at 03:57:06AM -0600, Jan Beulich wrote: > >>> On 06.05.19 at 10:04, <jgross@xxxxxxxx> wrote: > > On 05/05/2019 15:27, Marek Marczykowski-Górecki wrote: > >> Hi, > >> > >> I have a machine that allocate vesa LFB above 4GB, as reported by UEFI > >> GOP. At 0x4000000000 to be specific. > >> vga_console_info.u.vesa_lfb.lfb_base is a 32bit field, so it gets > >> truncated, leading to all kind of memory corruptions when something > >> writes there. > >> If that would be only about Xen, that wouldn't be that bad, but > >> unfortunately exactly the same structure is used as an interface for > >> dom0 start info (at least PV one). > >> My only idea is to introduce yet another entry in *_vga_console_info.u > >> union (efi_lfb64?) with a 64bit lfb_base field. And mark it in > >> video_type (XEN_VGATYPE_EFI_LFB64?). But I'm not sure how non-patched > >> Linux (or other supported OSes) would respond to this. xen_init_vga() in > >> Linux doesn't seem to bail on unknown video_type, so it may be fragile. > >> > >> Any better ideas? > > > > In Linux kernel the screen_info structure has ext_lfb_base for that > > purpose (it contains the upper 32 bits of lfb_base). > > > > We could add a similar member to Xen's dom0_vga_console_info.u.vesa_lfb > > and let the kernel detect its presence by using the value of > > start_info.console.dom0.info_size - this wouldn't require a new video > > type and old kernels would run as today. The same scheme is used for > > gbl_caps and mode_attrs already. > > +1 Makes sense. That said, in Linux, VIDEO_CAPABILITY_64BIT_BASE is 2, same as COMPAT bit Xen use in gbl_caps - which is later copied to screen_info->capabilities by Linux... Another interaction is that, all extra fields (gbl_caps, mode_attrs) are skipped with XEN_VGATYPE_EFI_LFB. It will look a little confusing that bit 2 means totally different things depending on video type. And to be honest, I'm not sure if Linux wouldn't interpret COMPAT bit wrong here. BTW another problem I have on this machine is the framebuffer size. It's 3840 x 2160, which is larger than max resolution hardcoded in drivers/video/lfb.c (1920 x 1200). efi_find_gop_mode() chooses the largest one, ignoring this limit. On one hand, it should take the limit into account, but on another, increasing the limit looks quite harmless (other than the console is quite slow) and not changing the mode during boot looks better. -- 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:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |