From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shannon Zhao Subject: Re: Design doc of adding ACPI support for arm64 on Xen - version 3 Date: Tue, 18 Aug 2015 15:23:54 +0800 Message-ID: <55D2DD8A.20706@huawei.com> References: <55CE0247.4030805@linaro.org> <55CE06A5.8050307@citrix.com> <55D1DB2D.6050807@linaro.org> <55D20788.9050503@citrix.com> <55D2A445.5020405@huawei.com> <55D2D25E.7020509@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55D2D25E.7020509@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall , Shannon Zhao , xen-devel@lists.xen.org, Christoffer Dall , Ian Campbell , stefano.stabellini@eu.citrix.com, Stefano Stabellini , JBeulich@suse.com, Parth Dixit , andrew@fubar.geek.nz, boris.ostrovsky@oracle.com, david.vrabel@citrix.com Cc: Hangaohuai , "Huangpeng (Peter)" List-Id: xen-devel@lists.xenproject.org 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