| Message ID | dfffbc1faf0884df46f5568cdcf9fa8c2340ae2b.1557154206.git-series.marmarek@invisiblethingslab.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Fixes for large framebuffer, placed above 4GB | expand |
On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote: > On some machines (for example Thinkpad P52), UEFI GOP reports > framebuffer located above 4GB (0x4000000000 on that machine). This > address does not fit in {xen,dom0}_vga_console_info.u.vesa_lfb.lfb_base > field, which is 32bit. The overflow here cause all kind of memory > corruption when anything tries to write something on the screen, > starting with zeroing the whole framebuffer in vesa_init(). > > Fix this similar to how it's done in Linux: add ext_lfb_base field at > the end of the structure, to hold upper 32bits of the address. Since the > field is added at the end of the structure, it will work with older > Linux versions too (other than using possibly truncated address - no > worse than without this change). Thanks to ABI containing size of the > structure (start_info.console.dom0.info_size), Linux can detect when > this field is present and use it appropriately then. > > Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> > --- > xen/arch/x86/efi/efi-boot.h | 1 + > xen/drivers/video/vesa.c | 15 +++++++++++---- > xen/include/public/xen.h | 2 ++ > 3 files changed, 14 insertions(+), 4 deletions(-) > > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h > index 5789d2c..7a13a30 100644 > --- a/xen/arch/x86/efi/efi-boot.h > +++ b/xen/arch/x86/efi/efi-boot.h > @@ -550,6 +550,7 @@ static void __init efi_arch_video_init(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, > vga_console_info.u.vesa_lfb.bytes_per_line = > (mode_info->PixelsPerScanLine * bpp + 7) >> 3; > vga_console_info.u.vesa_lfb.lfb_base = gop->Mode->FrameBufferBase; > + vga_console_info.u.vesa_lfb.ext_lfb_base = gop->Mode->FrameBufferBase >> 32; > vga_console_info.u.vesa_lfb.lfb_size = > (gop->Mode->FrameBufferSize + 0xffff) >> 16; > } > diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c > index c92497e..f22cf7f 100644 > --- 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; > > if ( !font ) > return; > @@ -97,15 +98,17 @@ void __init vesa_init(void) > lfbp.text_columns = vlfb_info.width / font->width; > lfbp.text_rows = vlfb_info.height / font->height; > > - lfbp.lfb = lfb = ioremap(vlfb_info.lfb_base, vram_remap); > + lfb_base = vlfb_info.lfb_base; > + lfb_base |= (unsigned long)vlfb_info.ext_lfb_base << 32; > + lfbp.lfb = lfb = ioremap(lfb_base, vram_remap); > if ( !lfb ) > return; > > memset(lfb, 0, vram_remap); > > - 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=%d, font %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 = vlfb_info.lfb_base; > + lfb_base |= (unsigned long)vlfb_info.ext_lfb_base << 32; > > if ( !lfb || (vesa_mtrr == 0) || (vesa_mtrr >= ARRAY_SIZE(mtrr_types)) ) > return; > @@ -167,7 +174,7 @@ void __init vesa_mtrr_init(void) > > /* Try and find a power of two to add */ > do { > - rc = mtrr_add(vlfb_info.lfb_base, size_total, type, 1); > + rc = mtrr_add(lfb_base, size_total, type, 1); > size_total >>= 1; > } while ( (size_total >= PAGE_SIZE) && (rc == -EINVAL) ); > } > 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). Juergen
On 06/05/2019 15:50, Marek Marczykowski-Górecki wrote: > diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c > index c92497e..f22cf7f 100644 > --- 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; This is common code, which is (in principle, although not currently) shared with arm32, where unsigned long isn't wide enough. Use paddr_t and PRIpaddr, which should be wide enough in any build. ~Andrew
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.
On 06/05/2019 17:32, Marek Marczykowski-Górecki 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. With the #ifdef...#endif just above your addition a consumer using an interface version < 0x00030206 could think gbl_caps is available instead of ext_lfb_base. Juergen
>>> On 06.05.19 at 16:50, <marmarek@invisiblethingslab.com> 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; > > if ( !font ) > return; > @@ -97,15 +98,17 @@ void __init vesa_init(void) > lfbp.text_columns = vlfb_info.width / font->width; > lfbp.text_rows = vlfb_info.height / font->height; > > - lfbp.lfb = lfb = ioremap(vlfb_info.lfb_base, vram_remap); > + lfb_base = vlfb_info.lfb_base; > + lfb_base |= (unsigned long)vlfb_info.ext_lfb_base << 32; > + lfbp.lfb = lfb = ioremap(lfb_base, vram_remap); > if ( !lfb ) > return; > > memset(lfb, 0, vram_remap); > > - 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=%d, font %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 = vlfb_info.lfb_base; > + lfb_base |= (unsigned long)vlfb_info.ext_lfb_base << 32; > > if ( !lfb || (vesa_mtrr == 0) || (vesa_mtrr >= ARRAY_SIZE(mtrr_types)) ) > return; > @@ -167,7 +174,7 @@ void __init vesa_mtrr_init(void) > > /* Try and find a power of two to add */ > do { > - rc = mtrr_add(vlfb_info.lfb_base, size_total, type, 1); > + rc = mtrr_add(lfb_base, size_total, type, 1); > size_total >>= 1; > } while ( (size_total >= PAGE_SIZE) && (rc == -EINVAL) ); > } Imo the result would be better readable if, instead of the local variables, you introduced an inline helper lfb_base(). Jan
>>> 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. Jan
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?
>>> On 07.05.19 at 17:38, <marmarek@invisiblethingslab.com> wrote: > 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. When the system is in a simple text mode the /basevideo option of xen.efi ought to help, but if it's in an LFB-based mode already (which is the case on the systems I have) then indeed I can't see any workaround. > Maybe, as a first step, a change that abort framebuffer initialization > if lfb_base == 0 (I assume this is never valid value here, right?)? Yes, that would be an option. But it would help only in your specific case, not if the truncation results in a non-zero value. I guess we'd better avoid filling the structure if we'd truncate the value. But what's wrong with backporting your change as is? > If not, then at least abort boot when text console is still there > (blexit before efi_exit_boot). Any preference? What's wrong with the text console still active? Or maybe I'm misunderstanding this point you make... Jan
On Tue, May 07, 2019 at 10:12:13AM -0600, Jan Beulich wrote: > >>> On 07.05.19 at 17:38, <marmarek@invisiblethingslab.com> wrote: > > 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. > > When the system is in a simple text mode the /basevideo option of > xen.efi ought to help, but if it's in an LFB-based mode already (which > is the case on the systems I have) then indeed I can't see any > workaround. > > > Maybe, as a first step, a change that abort framebuffer initialization > > if lfb_base == 0 (I assume this is never valid value here, right?)? > > Yes, that would be an option. But it would help only in your specific > case, not if the truncation results in a non-zero value. I guess we'd > better avoid filling the structure if we'd truncate the value. Yes, I was thinking about setting lfb_base=0 explicitly if it would overflow otherwise. > But what's wrong with backporting your change as is? If this commit would be backported, what value you'd put in that #ifdef? Also, one may argue that ABI changes should not be backported... But since there is clear and independent of xen version method of detecting it, I don't think this would be a big issue here. > > If not, then at least abort boot when text console is still there > > (blexit before efi_exit_boot). Any preference? > > What's wrong with the text console still active? Or maybe I'm > misunderstandint you make... As soon as you call ExitBootServices(), you can't use SIMPLE_TEXT_OUTPUT_INTERFACE anymore. Which means if a) framebuffer address didn't fit, and b) you called ExitBootServices() already, you don't have any means to tell the user what is wrong. Other than serial console of course, if you're lucky enough to have one. So the idea was to report the problem before ExitBootServices().
>>> On 07.05.19 at 18:43, <marmarek@invisiblethingslab.com> wrote: > On Tue, May 07, 2019 at 10:12:13AM -0600, Jan Beulich wrote: >> >>> On 07.05.19 at 17:38, <marmarek@invisiblethingslab.com> wrote: >> > 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. >> >> When the system is in a simple text mode the /basevideo option of >> xen.efi ought to help, but if it's in an LFB-based mode already (which >> is the case on the systems I have) then indeed I can't see any >> workaround. >> >> > Maybe, as a first step, a change that abort framebuffer initialization >> > if lfb_base == 0 (I assume this is never valid value here, right?)? >> >> Yes, that would be an option. But it would help only in your specific >> case, not if the truncation results in a non-zero value. I guess we'd >> better avoid filling the structure if we'd truncate the value. > > Yes, I was thinking about setting lfb_base=0 explicitly if it would > overflow otherwise. > >> But what's wrong with backporting your change as is? > > If this commit would be backported, what value you'd put in that #ifdef? I'd keep it as is. The field addition happens for 4.13. And as you say ... > Also, one may argue that ABI changes should not be backported... But > since there is clear and independent of xen version method of detecting > it, I don't think this would be a big issue here. ... there's not really any issue with surfacing this also in older versions. >> > If not, then at least abort boot when text console is still there >> > (blexit before efi_exit_boot). Any preference? >> >> What's wrong with the text console still active? Or maybe I'm >> misunderstandint you make... > > As soon as you call ExitBootServices(), you can't use > SIMPLE_TEXT_OUTPUT_INTERFACE anymore. Which means if a) framebuffer > address didn't fit, and b) you called ExitBootServices() already, you > don't have any means to tell the user what is wrong. Other than serial > console of course, if you're lucky enough to have one. So the idea was > to report the problem before ExitBootServices(). Oh, so be "text console" you meant the EFI interface, not a console in text mode (which we can drive). Failing to boot in such a case seems worse to me than booting effectively headless. Jan
On Wed, May 08, 2019 at 03:54:45AM -0600, Jan Beulich wrote: > >>> On 07.05.19 at 18:43, <marmarek@invisiblethingslab.com> wrote: > > On Tue, May 07, 2019 at 10:12:13AM -0600, Jan Beulich wrote: > >> >>> On 07.05.19 at 17:38, <marmarek@invisiblethingslab.com> wrote: > >> > 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. > >> > >> When the system is in a simple text mode the /basevideo option of > >> xen.efi ought to help, but if it's in an LFB-based mode already (which > >> is the case on the systems I have) then indeed I can't see any > >> workaround. > >> > >> > Maybe, as a first step, a change that abort framebuffer initialization > >> > if lfb_base == 0 (I assume this is never valid value here, right?)? > >> > >> Yes, that would be an option. But it would help only in your specific > >> case, not if the truncation results in a non-zero value. I guess we'd > >> better avoid filling the structure if we'd truncate the value. > > > > Yes, I was thinking about setting lfb_base=0 explicitly if it would > > overflow otherwise. > > > >> But what's wrong with backporting your change as is? > > > > If this commit would be backported, what value you'd put in that #ifdef? > > I'd keep it as is. The field addition happens for 4.13. And as you say ... > > > Also, one may argue that ABI changes should not be backported... But > > since there is clear and independent of xen version method of detecting > > it, I don't think this would be a big issue here. > > ... there's not really any issue with surfacing this also in older > versions. You mean to keep it without #ifdef then? I'm not following... If you add #ifdef __XEN_INTERFACE_VERSION__ >= 0x00040d00 there, the field won't be available in Xen < 4.13. Which effectively means the patch can't be backported as it won't compile with Xen < 4.13. Note also that this structure is the place that Xen use to keep that information internally (xen_vga_console_info is another name for dom0_vga_console_info), it isn't only about passing this information to dom0. Maybe add #ifdef __XEN_INTERFACE_VERSION__ >= 0x00040a00, as the oldest fully supported version? This will mitigate one of the issues with the lack of #ifdef (potential conflict with gbl_caps with __XEN_INTERFACE_VERSION__ < 0x00030206). Or use some #if meaning Xen interface >= 4.13, or Xen internal build? > >> > If not, then at least abort boot when text console is still there > >> > (blexit before efi_exit_boot). Any preference? > >> > >> What's wrong with the text console still active? Or maybe I'm > >> misunderstandint you make... > > > > As soon as you call ExitBootServices(), you can't use > > SIMPLE_TEXT_OUTPUT_INTERFACE anymore. Which means if a) framebuffer > > address didn't fit, and b) you called ExitBootServices() already, you > > don't have any means to tell the user what is wrong. Other than serial > > console of course, if you're lucky enough to have one. So the idea was > > to report the problem before ExitBootServices(). > > Oh, so be "text console" you meant the EFI interface, not a > console in text mode (which we can drive). Failing to boot in > such a case seems worse to me than booting effectively > headless. Yes, if the alternative is booting headless, then indeed it's better than refusing to boot with a message. But if the alternative is a mysterious crash without any message...
>>> On 08.05.19 at 14:06, <marmarek@invisiblethingslab.com> wrote: > On Wed, May 08, 2019 at 03:54:45AM -0600, Jan Beulich wrote: >> >>> On 07.05.19 at 18:43, <marmarek@invisiblethingslab.com> wrote: >> > On Tue, May 07, 2019 at 10:12:13AM -0600, Jan Beulich wrote: >> >> But what's wrong with backporting your change as is? >> > >> > If this commit would be backported, what value you'd put in that #ifdef? >> >> I'd keep it as is. The field addition happens for 4.13. And as you say ... >> >> > Also, one may argue that ABI changes should not be backported... But >> > since there is clear and independent of xen version method of detecting >> > it, I don't think this would be a big issue here. >> >> ... there's not really any issue with surfacing this also in older >> versions. > > You mean to keep it without #ifdef then? I'm not following... If you add > #ifdef __XEN_INTERFACE_VERSION__ >= 0x00040d00 there, the field won't be > available in Xen < 4.13. Which effectively means the patch can't be > backported as it won't compile with Xen < 4.13. Note also that this > structure is the place that Xen use to keep that information internally > (xen_vga_console_info is another name for dom0_vga_console_info), it > isn't only about passing this information to dom0. Hmm, yes, I've been mixing up things. It would need to have "|| defined(__XEN__)" added there. > Maybe add #ifdef __XEN_INTERFACE_VERSION__ >= 0x00040a00, as the oldest > fully supported version? This will mitigate one of the issues with the > lack of #ifdef (potential conflict with gbl_caps with > __XEN_INTERFACE_VERSION__ < 0x00030206). That's not an option imo, as only some minor versions of those major ones would support the new field. Jan
On Tue, May 07, 2019 at 03:07:27AM -0600, Jan Beulich wrote: > >>> On 06.05.19 at 16:50, <marmarek@invisiblethingslab.com> 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; > > > > if ( !font ) > > return; > > @@ -97,15 +98,17 @@ void __init vesa_init(void) > > lfbp.text_columns = vlfb_info.width / font->width; > > lfbp.text_rows = vlfb_info.height / font->height; > > > > - lfbp.lfb = lfb = ioremap(vlfb_info.lfb_base, vram_remap); > > + lfb_base = vlfb_info.lfb_base; > > + lfb_base |= (unsigned long)vlfb_info.ext_lfb_base << 32; > > + lfbp.lfb = lfb = ioremap(lfb_base, vram_remap); > > if ( !lfb ) > > return; > > > > memset(lfb, 0, vram_remap); > > > > - 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=%d, font %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 = vlfb_info.lfb_base; > > + lfb_base |= (unsigned long)vlfb_info.ext_lfb_base << 32; > > > > if ( !lfb || (vesa_mtrr == 0) || (vesa_mtrr >= ARRAY_SIZE(mtrr_types)) ) > > return; > > @@ -167,7 +174,7 @@ void __init vesa_mtrr_init(void) > > > > /* Try and find a power of two to add */ > > do { > > - rc = mtrr_add(vlfb_info.lfb_base, size_total, type, 1); > > + rc = mtrr_add(lfb_base, size_total, type, 1); > > size_total >>= 1; > > } while ( (size_total >= PAGE_SIZE) && (rc == -EINVAL) ); > > } > > 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.
>>> On 09.05.19 at 02:22, <marmarek@invisiblethingslab.com> wrote: > On Tue, May 07, 2019 at 03:07:27AM -0600, Jan Beulich wrote: >> >>> On 06.05.19 at 16:50, <marmarek@invisiblethingslab.com> 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; >> > >> > if ( !font ) >> > return; >> > @@ -97,15 +98,17 @@ void __init vesa_init(void) >> > lfbp.text_columns = vlfb_info.width / font->width; >> > lfbp.text_rows = vlfb_info.height / font->height; >> > >> > - lfbp.lfb = lfb = ioremap(vlfb_info.lfb_base, vram_remap); >> > + lfb_base = vlfb_info.lfb_base; >> > + lfb_base |= (unsigned long)vlfb_info.ext_lfb_base << 32; >> > + lfbp.lfb = lfb = ioremap(lfb_base, vram_remap); >> > if ( !lfb ) >> > return; >> > >> > memset(lfb, 0, vram_remap); >> > >> > - 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=%d, font %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 = vlfb_info.lfb_base; >> > + lfb_base |= (unsigned long)vlfb_info.ext_lfb_base << 32; >> > >> > if ( !lfb || (vesa_mtrr == 0) || (vesa_mtrr >= ARRAY_SIZE(mtrr_types)) ) >> > return; >> > @@ -167,7 +174,7 @@ void __init vesa_mtrr_init(void) >> > >> > /* Try and find a power of two to add */ >> > do { >> > - rc = mtrr_add(vlfb_info.lfb_base, size_total, type, 1); >> > + rc = mtrr_add(lfb_base, size_total, type, 1); >> > size_total >>= 1; >> > } while ( (size_total >= PAGE_SIZE) && (rc == -EINVAL) ); >> > } >> >> 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). Anonymous structures can, iirc, be easily have their type used by using typeof(). But indeed I was thinking about a parameter-less function or macro as a possible option. > 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. To be honest, I've noticed this while putting together the previous reply, and I didn't think it would by any problem in the slightest. Jan
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 5789d2c..7a13a30 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -550,6 +550,7 @@ static void __init efi_arch_video_init(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, vga_console_info.u.vesa_lfb.bytes_per_line = (mode_info->PixelsPerScanLine * bpp + 7) >> 3; vga_console_info.u.vesa_lfb.lfb_base = gop->Mode->FrameBufferBase; + vga_console_info.u.vesa_lfb.ext_lfb_base = gop->Mode->FrameBufferBase >> 32; vga_console_info.u.vesa_lfb.lfb_size = (gop->Mode->FrameBufferSize + 0xffff) >> 16; } diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c index c92497e..f22cf7f 100644 --- 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; if ( !font ) return; @@ -97,15 +98,17 @@ void __init vesa_init(void) lfbp.text_columns = vlfb_info.width / font->width; lfbp.text_rows = vlfb_info.height / font->height; - lfbp.lfb = lfb = ioremap(vlfb_info.lfb_base, vram_remap); + lfb_base = vlfb_info.lfb_base; + lfb_base |= (unsigned long)vlfb_info.ext_lfb_base << 32; + lfbp.lfb = lfb = ioremap(lfb_base, vram_remap); if ( !lfb ) return; memset(lfb, 0, vram_remap); - 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=%d, font %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 = vlfb_info.lfb_base; + lfb_base |= (unsigned long)vlfb_info.ext_lfb_base << 32; if ( !lfb || (vesa_mtrr == 0) || (vesa_mtrr >= ARRAY_SIZE(mtrr_types)) ) return; @@ -167,7 +174,7 @@ void __init vesa_mtrr_init(void) /* Try and find a power of two to add */ do { - rc = mtrr_add(vlfb_info.lfb_base, size_total, type, 1); + rc = mtrr_add(lfb_base, size_total, type, 1); size_total >>= 1; } while ( (size_total >= PAGE_SIZE) && (rc == -EINVAL) ); } 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; } vesa_lfb; } u; } dom0_vga_console_info_t;
On some machines (for example Thinkpad P52), UEFI GOP reports framebuffer located above 4GB (0x4000000000 on that machine). This address does not fit in {xen,dom0}_vga_console_info.u.vesa_lfb.lfb_base field, which is 32bit. The overflow here cause all kind of memory corruption when anything tries to write something on the screen, starting with zeroing the whole framebuffer in vesa_init(). Fix this similar to how it's done in Linux: add ext_lfb_base field at the end of the structure, to hold upper 32bits of the address. Since the field is added at the end of the structure, it will work with older Linux versions too (other than using possibly truncated address - no worse than without this change). Thanks to ABI containing size of the structure (start_info.console.dom0.info_size), Linux can detect when this field is present and use it appropriately then. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> --- xen/arch/x86/efi/efi-boot.h | 1 + xen/drivers/video/vesa.c | 15 +++++++++++---- xen/include/public/xen.h | 2 ++ 3 files changed, 14 insertions(+), 4 deletions(-)