Re: [PATCH v3 4/9] x86/PVH: provide VGA console info to Dom0

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.09.2021 19:03, Andrew Cooper wrote:
> On 22/09/2021 16:01, Roger Pau Monné wrote:
>> On Tue, Sep 21, 2021 at 09:18:05AM +0200, Jan Beulich wrote:
>>> --- a/xen/include/public/arch-x86/hvm/start_info.h
>>> +++ b/xen/include/public/arch-x86/hvm/start_info.h
>>> @@ -33,7 +33,7 @@
>>>   *    | magic          | Contains the magic value XEN_HVM_START_MAGIC_VALUE
>>>   *    |                | ("xEn3" with the 0x80 bit of the "E" set).
>>>   *  4 +----------------+
>>> - *    | version        | Version of this structure. Current version is 1. 
>>> New
>>> + *    | version        | Version of this structure. Current version is 2. 
>>> New
>>>   *    |                | versions are guaranteed to be 
>>> backwards-compatible.
>>>   *  8 +----------------+
>>>   *    | flags          | SIF_xxx flags.
>>> @@ -55,7 +55,15 @@
>>>   *    |                | if there is no memory map being provided. Only
>>>   *    |                | present in version 1 and newer of the structure.
>>>   * 52 +----------------+
>>> - *    | reserved       | Version 1 and newer only.
>>> + *    | vga_info.offset| Offset of struct dom0_vga_console_info from base 
>>> of
>> I'm not sure we are supposed to reference external structures like
>> that. We took a lot of care to not depend on other headers, and to
>> make this as agnostic as possible (IIRC KVM is also capable of using
>> the PVH entry point natively, and hence depends on this header).
> 
> Absolutely correct.  C is not an acceptable ABI description.

See my reply to Roger's earlier mail.

> Furthermore, dom0_vga_console_info is a bad ABI to start with, as
> demonstrated by the multiple problems we've had extending it in the past.

I don't view this as "problems", nor do I think we couldn't extend it
further that same way, if need be.

> The MB1/2 framebuffer information would be a rather better example to
> follow,

Maybe, but I'm not sure - it doesn't look any better extensibility-wise
than dom0_vga_console_info. Also MB1 doesn't really have separate
structures, so if anything it would need to be MB2.

> but we'll surely need to pass the EDID string too (at least in
> the case that there aren't EFI runtime services to use).

According to the understanding I've gained while putting together the
patch to retrieve EDID info when running under EFI, there's no way to
obtain these via runtime services. Yet I also don't see why we would
need to pass this here - we've got XENPF_firmware_info to retrieve
this data, and I didn't think we need PVH to behave differently from
PV in such regards.

Jan