Re: UEFI support in ARM DomUs

[Julien Grall <julien@xen.org>]

On 22/06/2020 15:33, Oleksandr Andrushchenko wrote:
> 
> On 6/22/20 5:27 PM, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 22/06/2020 15:04, Oleksandr Andrushchenko wrote:
>>> On 6/19/20 11:02 PM, Stefano Stabellini wrote:
>>>> On Thu, 18 Jun 2020, Julien Grall wrote:
>>> 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.
>>
>> Sorry if this was already asked before. Why do you need to specify __XEN_INTERFACE_VERSION__?
> 
> This is because of include/xen/interface/xen-compat.h:
> 
> #if defined(__XEN__) || defined(__XEN_TOOLS__)
> 
> /* Xen is built with matching headers and implements the latest interface. */
> #define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__
> #elif !defined(__XEN_INTERFACE_VERSION__)
> /* Guests which do not specify a version get the legacy interface. */
> #define __XEN_INTERFACE_VERSION__ 0x00000000
> #endif

I am afraid this doesn't explain why you need to define it to a specific 
version.

__XEN_INTERFACE_VERSION__ is really mostly here to allow a guest to 
build if they rely on header from xen.git (we may have done some 
renaming). Most (if not all) the interfaces you care ought to be stable.

Older Xen will return -ENOSYS/-EOPNOTSUPP should deny any values they 
don't know.

As you pull the headers in U-boot, you could safely define 
__XEN_INTERFACE_VERSION__ as __XEN_LATEST_INTERFACE_VERSION__. FWIW, 
this is what Linux is doing to some extend.

Note that I haven't suggested to keep __XEN_INTERFACE_VERSION__ as 
0x00000000 because it looks like it is going to do the wrong thing on 
arm32 :(.

I have at least spot one issue with GNTTABOP_setup_table where it will 
use unsigned long (i.e 32-bit) for older interface. But the hypervisor 
will always 64-bits.

This probably going to result to some overwrite. I think we should fix 
the headers to force it to use xen_pfn_t for all Xen on Arm version.

Something like:

#if !(defined(__arch64__) || defined(__arm__)) && 
__XEN_INTERFACE_VERSION__ < 0x00040300
     XEN_GUEST_HANDLE(ulong) frame_list;
#else
     XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
#endif

> 
> So, one needs to specify the version (QEMU does that via its configure script after
> 
> some tests)

Well libxc is definitely not stable, hence why QEMU requires to specify 
the version. But the interface with the guest is always meant to be stable.

>>
>>>
>>> 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.
>>
>> __XEN_INTERFACE_VERSION__ should work through the CFLAGS. An alternative would be to allow the user to specify through the Kconfig.
> 
> You mean specifying via Kconfig something like "0x00040d00"?

Possibly yes.

> 
> And what about the headers? How will we provide their location if we decide not to include those
> 
> in the tree?

I would do through Kconfig as well.

Cheers,

-- 
Julien Grall