Re: UEFI support in ARM DomUs

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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).

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 :-)