On Thu, May 16, 2019 at 08:59:36AM -0600, Jan Beulich wrote: > >>> On 16.05.19 at 16:07, <[email protected]> wrote: > > --- a/xen/drivers/video/vesa.c > > +++ b/xen/drivers/video/vesa.c > > @@ -40,6 +40,11 @@ static int __init parse_font_height(const char *s) > > } > > custom_param("font", parse_font_height); > > > > +static inline paddr_t lfb_base(void) > > +{ > > + return (paddr_t)((vlfb_info.ext_lfb_base) << 32) | vlfb_info.lfb_base; > > I'm afraid you've misplaced the parentheses here. I wonder if > this has worked for you at all.
Indeed it's messed up...
> return ((paddr_t)vlfb_info.ext_lfb_base << 32) | vlfb_info.lfb_base;
This works fine.
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -923,6 +923,11 @@ typedef struct dom0_vga_console_info {
> > /* Mode attributes (offset 0x0, VESA command 0x4f01). */
> > uint16_t mode_attrs;
> > #endif
> > +#if __XEN_INTERFACE_VERSION__ >= 0x00040d00
> > + uint16_t _pad;
And also compat checker don't like this name. I've changed it to "pad"
(v4 upcoming).
> > + /* high 32 bits of lfb_base */
> > + uint32_t ext_lfb_base;
> > +#endif
>
> Strictly speaking the padding field belongs ahead of the earlier
> #endif.
>
> Both aspects can be fixed while committing, but confirmation on
> the first wrt it working for you would still be nice. With them in
> place
> Reviewed-by: Jan Beulich <[email protected]>
--
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?
signature.asc
Description: PGP signature
_______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
