Re: UEFI support in ARM DomUs

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>]

On 6/19/20 11:02 PM, Stefano Stabellini wrote:
> On Thu, 18 Jun 2020, Julien Grall wrote:
>>> Copy/pasting here from my comment on the pull request plus additional
>>> thoughts.
>>>
>>> Uboot is one of those embedded projects that typically assumes that all
>>> the information about the platform is available at *build time*. It is
>>> meant to be built tailored for a specific version of a specific board. A
>>> Uboot binary is not expected to be "portable" across different versions
>>> of the platform or different platforms. In other words, it is not
>>> expected to be portable across Xen versions.
>> Can you define "version" here? Do you refer to the difference in terms
>> of memory?
>   
> Yes, I meant any meaningful differences in any of the external
> interfaces that end up impacting the UBoot implementation. A primary
> example would be the memory addresses for instance.
>
>
>>> This is a different model meant for different use-cases. I don't think
>>> it is a problem "philosophically" to let Uboot know about Xen details at
>>> build time. Yes, that is not what we did historically but it is very
>>> much in the spirit of Uboot.
>> TBH, I don't particularly mind that U-boot is built against a specific
>> version of Xen. I am more concerned about the long term implication if
>> we endorse it
>> and then try to change the memory layout in depth.
> I'll provide more information below.
>
>
>>> But of course the least Uboot depends on these details the better
>>> because it will be more flexible, but it could very well be that we
>>> won't be able to reach the point where the binary works on any version
>>> like we did with Tianocore. The two projects work differently.
>> Can we have a list of things U-boot require to know at compile time?
>>
>> In particular, I would like to understand if it would be sufficient to
>> only be aware of the first bank. If it is, then my preference would be
>> to standardize that bit of the layout.
> That would be my preference too, and it was great to read that it looks
> like it can be done. Yay!
>
>
>>> That said, I think Julien is right that we need to be careful on how we
>>> expose these information to Uboot, i.e. defining __XEN__ to build Uboot
>>> doesn't seem like a good idea because we enable definitions that were
>>> never meant to be used outside of a Xen build. Also, it wouldn't be easy
>>> to know exactly which definitions are actively used by Uboot and which
>>> ones aren't.
>>>
>>> If we are going to make Uboot dependent on version-specific information
>>> of the Xen interface, it would be better to be very clear about which
>>> definitions we are using. So that one day if we need to change them, we
>>> can find them easily.
>>>
>>> So I think it would be better to introduce a set of defines with the
>>> minimum amount of information required by Uboot statically. That way,
>>> at least we have a single place where to find all the version-specific
>>> definitions that Uboot is using.
>> I am not sure what you are suggesting. Can you expand a bit more?
>>
>>> We can also manage versioning of the
>>> Xen interface (like we do in QEMU) if we have to.
>> Can you provide more details about the compatibility? I am quite
>> interested in the part where you would have to deal with an older QEMU
>> version built against a new Xen?
> Sure let me expand a bit more. I'll switch "hat" to "QEMU (or UBoot)
> contributor" for the sake of this discussion.
>
> Xen Project offers certain stability guarantees on some interfaces and
> not others. Let's say that for any reason you have to or want to use one
> of the unstable interfaces in QEMU/UBoot/Whatever. Then it becomes your
> responsibility as QEMU developer to maintain compatibility in QEMU
> itself.
>
> First I'd add code to detect the version of the interface. The detection
> is based on the Xen headers/libraries provided. In QEMU it is done in
> the "configure" script. It sets a preprocessor #define to the version
> of the interface (e.g. CONFIG_XEN_CTRL_INTERFACE_VERSION == 41100).

I looked at QEMU's configure script and I'm afraid we can't have the

same flexibility in U-boot: we don't have configure script, pkg-config

is not widely used etc. So, for now we have hardcoded:

ifeq ($(CONFIG_XEN),y)
arch-y += -D__XEN_INTERFACE_VERSION__=0x00040d00
endif

and we also have Xen 4.13 headers in the U-boot tree.

For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it via

CFLAGS or something. This can also be done for the location of Xen headers.

We don't have strong opinion here, so would love to hear from Xen community on this

Current WIP with the fixes requested by Julien are at [1]: can be and will be force pushed

as we are still working on it, but can give you an impression of what we have as of now

>
> Then you can have preprocessors checks in one of the headers such as:
>
> #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40701
>      #define xenevtchn_open(l, f) xc_evtchn_open(l, f);
> #else
>      XXX
> #endif
>
>
> And also like:
>
> #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40600
>
> #ifndef HVM_IOREQSRV_BUFIOREQ_ATOMIC
> #define HVM_IOREQSRV_BUFIOREQ_ATOMIC 2
> #endif
>
> #endif
>
>
> This works OK to handle differences in the interface between past
> versions of Xen. What about building an older QEMU against a new version
> of Xen? That is not going to work if something changes again on the Xen
> side. However, it becomes much easier to add support for the new Xen
> interface in QEMU, because you can go and look at that compatibility
> header and just add the right #else XXX. It also makes it clear what
> interfaces and definitions have been used that are unstable.
>
> Of course it is better to use the stable interfaces when possible :-)
[1] https://github.com/andr2000/u-boot/tree/pvblock_upstream_v1