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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.05.19 at 14:06, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, May 08, 2019 at 03:54:45AM -0600, Jan Beulich wrote:
>> >>> On 07.05.19 at 18:43, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel