All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@citrix.com>
To: Shannon Zhao <zhaoshenglong@huawei.com>,
	Shannon Zhao <shannon.zhao@linaro.org>,
	xen-devel@lists.xen.org,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	stefano.stabellini@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	JBeulich@suse.com, Parth Dixit <parth.dixit@linaro.org>,
	andrew@fubar.geek.nz, boris.ostrovsky@oracle.com,
	david.vrabel@citrix.com
Cc: Hangaohuai <hangaohuai@huawei.com>,
	"Huangpeng (Peter)" <peter.huangpeng@huawei.com>
Subject: Re: Design doc of adding ACPI support for arm64 on Xen - version 3
Date: Tue, 18 Aug 2015 09:13:19 -0700	[thread overview]
Message-ID: <55D3599F.6070107@citrix.com> (raw)
In-Reply-To: <55D2DD8A.20706@huawei.com>



On 18/08/2015 00:23, Shannon Zhao wrote:
>
>
> 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

Which is not QEMU but Linux...

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

Please read again my previous mail. The properties are created by the 
EFI stub (compiled within the Kernel) and neither UEFI firmware nor Xen.

Regards,

-- 
Julien Grall

  reply	other threads:[~2015-08-18 16:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-14 14:59 Design doc of adding ACPI support for arm64 on Xen - version 3 Shannon Zhao
2015-08-14 15:17 ` Julien Grall
2015-08-17 13:01   ` Shannon Zhao
2015-08-17 16:10     ` Julien Grall
2015-08-18  3:19       ` Shannon Zhao
2015-08-18  6:36         ` Julien Grall
2015-08-18  7:23           ` Shannon Zhao
2015-08-18 16:13             ` Julien Grall [this message]
2015-08-14 15:59 ` Konrad Rzeszutek Wilk
2015-08-17 15:33 ` Jan Beulich
2015-08-17 16:19   ` Julien Grall
2015-08-18  5:10     ` Jan Beulich
2015-08-18  6:43       ` Julien Grall
2015-08-18  7:01         ` Jan Beulich
2015-08-18  7:46           ` Shannon Zhao
2015-08-18 19:01           ` Julien Grall
2015-08-18  3:41   ` Shannon Zhao
2015-08-18  5:14     ` Jan Beulich
2015-08-18  7:35       ` Shannon Zhao
2015-08-18  8:15         ` Jan Beulich
2015-08-18  8:21           ` Shannon Zhao
2015-08-18  9:11             ` Jan Beulich
2015-08-18  9:34               ` Shannon Zhao
2015-08-18 19:00                 ` Julien Grall
2015-09-02 11:43                   ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55D3599F.6070107@citrix.com \
    --to=julien.grall@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew@fubar.geek.nz \
    --cc=boris.ostrovsky@oracle.com \
    --cc=christoffer.dall@linaro.org \
    --cc=david.vrabel@citrix.com \
    --cc=hangaohuai@huawei.com \
    --cc=ian.campbell@citrix.com \
    --cc=parth.dixit@linaro.org \
    --cc=peter.huangpeng@huawei.com \
    --cc=shannon.zhao@linaro.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=zhaoshenglong@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.