[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 |