|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |