* [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-06 14:50 ` Marek Marczykowski-Górecki
0 siblings, 0 replies; 60+ messages in thread
From: Marek Marczykowski-Górecki @ 2019-05-06 14:50 UTC (permalink / raw)
To: xen-devel
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson,
Marek Marczykowski-Górecki, Tim Deegan, Julien Grall,
Jan Beulich, Roger Pau Monné
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;
} vesa_lfb;
} u;
} dom0_vga_console_info_t;
--
git-series 0.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 60+ messages in thread* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-06 15:15 ` Juergen Gross
0 siblings, 0 replies; 60+ messages in thread
From: Juergen Gross @ 2019-05-06 15:15 UTC (permalink / raw)
To: Marek Marczykowski-Górecki, xen-devel
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Julien Grall, Jan Beulich, Roger Pau Monné
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-06 15:15 ` Juergen Gross
0 siblings, 0 replies; 60+ messages in thread
From: Juergen Gross @ 2019-05-06 15:15 UTC (permalink / raw)
To: Marek Marczykowski-Górecki, xen-devel
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Julien Grall, Jan Beulich, Roger Pau Monné
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-06 15:32 ` Marek Marczykowski-Górecki
0 siblings, 0 replies; 60+ messages in thread
From: Marek Marczykowski-Górecki @ 2019-05-06 15:32 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Julien Grall, Jan Beulich, xen-devel, Roger Pau Monné
[-- Attachment #1.1: Type: text/plain, Size: 1122 bytes --]
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.
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-06 15:32 ` Marek Marczykowski-Górecki
0 siblings, 0 replies; 60+ messages in thread
From: Marek Marczykowski-Górecki @ 2019-05-06 15:32 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Julien Grall, Jan Beulich, xen-devel, Roger Pau Monné
[-- Attachment #1.1: Type: text/plain, Size: 1122 bytes --]
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.
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 5:07 ` Juergen Gross
0 siblings, 0 replies; 60+ messages in thread
From: Juergen Gross @ 2019-05-07 5:07 UTC (permalink / raw)
To: Marek Marczykowski-Górecki
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Julien Grall, Jan Beulich, xen-devel, Roger Pau Monné
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 5:07 ` Juergen Gross
0 siblings, 0 replies; 60+ messages in thread
From: Juergen Gross @ 2019-05-07 5:07 UTC (permalink / raw)
To: Marek Marczykowski-Górecki
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Julien Grall, Jan Beulich, xen-devel, Roger Pau Monné
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 9:10 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-07 9:10 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 9:10 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-07 9:10 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 15:38 ` Marek Marczykowski
0 siblings, 0 replies; 60+ messages in thread
From: Marek Marczykowski @ 2019-05-07 15:38 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
[-- 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
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 15:38 ` Marek Marczykowski
0 siblings, 0 replies; 60+ messages in thread
From: Marek Marczykowski @ 2019-05-07 15:38 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
[-- 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
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 16:12 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-07 16:12 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 16:12 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-07 16:12 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 16:43 ` Marek Marczykowski
0 siblings, 0 replies; 60+ messages in thread
From: Marek Marczykowski @ 2019-05-07 16:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
[-- Attachment #1.1: Type: text/plain, Size: 2184 bytes --]
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().
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 16:43 ` Marek Marczykowski
0 siblings, 0 replies; 60+ messages in thread
From: Marek Marczykowski @ 2019-05-07 16:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
[-- Attachment #1.1: Type: text/plain, Size: 2184 bytes --]
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().
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-08 9:54 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-08 9:54 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-08 9:54 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-08 9:54 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-08 12:06 ` Marek Marczykowski
0 siblings, 0 replies; 60+ messages in thread
From: Marek Marczykowski @ 2019-05-08 12:06 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
[-- Attachment #1.1: Type: text/plain, Size: 3809 bytes --]
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...
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-08 12:06 ` Marek Marczykowski
0 siblings, 0 replies; 60+ messages in thread
From: Marek Marczykowski @ 2019-05-08 12:06 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
[-- Attachment #1.1: Type: text/plain, Size: 3809 bytes --]
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...
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-08 12:45 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-08 12:45 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-08 12:45 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-08 12:45 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-06 15:28 ` Andrew Cooper
0 siblings, 0 replies; 60+ messages in thread
From: Andrew Cooper @ 2019-05-06 15:28 UTC (permalink / raw)
To: Marek Marczykowski-Górecki, xen-devel
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Tim Deegan, Ian Jackson, Julien Grall,
Jan Beulich, Roger Pau Monné
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-06 15:28 ` Andrew Cooper
0 siblings, 0 replies; 60+ messages in thread
From: Andrew Cooper @ 2019-05-06 15:28 UTC (permalink / raw)
To: Marek Marczykowski-Górecki, xen-devel
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Tim Deegan, Ian Jackson, Julien Grall,
Jan Beulich, Roger Pau Monné
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 9:07 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-07 9:07 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-07 9:07 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-07 9:07 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-09 0:22 ` Marek Marczykowski
0 siblings, 0 replies; 60+ messages in thread
From: Marek Marczykowski @ 2019-05-09 0:22 UTC (permalink / raw)
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
[-- Attachment #1.1: Type: text/plain, Size: 3102 bytes --]
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.
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-09 0:22 ` Marek Marczykowski
0 siblings, 0 replies; 60+ messages in thread
From: Marek Marczykowski @ 2019-05-09 0:22 UTC (permalink / raw)
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
[-- Attachment #1.1: Type: text/plain, Size: 3102 bytes --]
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.
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-09 8:59 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-09 8:59 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [Xen-devel] [PATCH 4/5] xen: fix handling framebuffer located above 4GB
@ 2019-05-09 8:59 ` Jan Beulich
0 siblings, 0 replies; 60+ messages in thread
From: Jan Beulich @ 2019-05-09 8:59 UTC (permalink / raw)
To: Marek Marczykowski
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Julien Grall, xen-devel, Roger Pau Monne
>>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 60+ messages in thread