Re: Design doc of adding ACPI support for arm64 on Xen - version 3

[Shannon Zhao <zhaoshenglong@huawei.com>]

On 2015/8/18 14:36, Julien Grall wrote:
> 
> 
> On 17/08/2015 20:19, Shannon Zhao wrote:
>>>> Yes, I think it's good to drop the "linux," too. But if we drop the
>>>> linux, would it impact the linux kernel booting with UEFI? And why we
>>>> don't do it to Xen since Xen still uses "linux,"?
>>>
>>> I don't understand your second question.
>>>
>> I mean that Xen is using the property "linux,uefi*" as well, and why we
>> don't drop that prefix for Xen?
> 
> As never say we shouldn't drop it in Xen... It's of course a nice clean
> up to have if we ever happen to standardize the properties with a
> different name.
> 
>>> For the first question, as we discussed in several mail, the property
>>> "linux,uefi-*" are only used internally between the stub and Linux. The
>>> sub is compiled in the kernel so there is no issue to change the
>>> property.
>>>
>> Since Linux defines the dt_params like below which is used to get EFI
>> info from DT, if we drop "linux," in Xen, does it need to drop the
>> "linux," in dt_params? If so, will this break the compatibility of
>> changed kernel with old UEFI? IIUC, there is not only Xen using these
>> properties, but also native host and QEMU guest.
> 
> I grepped "linux," and didn't spot any "linux,uefi-*" strings.
> 

In drivers/firmware/efi/efi.c line 478


static __initdata struct {
	const char name[32];
	const char propname[32];
	int offset;
	int size;
} dt_params[] = {
	UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
	UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
	UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
	UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
};

> Anyway, why are you speaking about old UEFI? As said in different mail,
> the linux,uefi-* properties are only used internally between the EFI
> stub and the kernel. Both are living in the same binary so it's not
> exposed outside.
> 

UEFI makes this minimal DT, right? To Dom0, Xen makes this minimal DT,
right? And EFI stub parses this DT through efi_get_fdt_params ==>
fdt_find_uefi_params in drivers/firmware/efi/efi.c. And
fdt_find_uefi_params uses dt_params[i].propname (e.g.
"linux,uefi-system-table") to get the matched property.

"prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);"

If we changed the property names in minimal DT but not change the
definition of dt_params[], it can't get the matched properties, right?
And if we both changed the property name in minimal DT and definition of
dt_params[], will this new kernel work well with the old UEFI which
still uses old property names to create the minimal DT?

> Those properties are not standardize so it would be wrong to use them to
> talk to the kernel.
> 
> Note that on Xen, we also used them internally. They were name
> "linux,uefi-*" because we re-use a part of the EFI stub from Linux. The
> names don't matter, so we can rename it without any issue
> 
> Regards,
> 

-- 
Shannon