Re: [Xen-devel] [PATCH RFC 00/19] arm64 EFI stub

[Roy Franz <roy.franz@xxxxxxxxxx>]

On Thu, Jul 10, 2014 at 12:58 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2014-07-09 at 11:24 -0700, Roy Franz wrote:
>> >> +    if ( fdtfile->ptr )
>> >> +        fdt_size = fdt_totalsize(fdtfile->ptr);
>> >> +    else
>> >> +    {
>> >> +        /* RFRANZ_TODO - missing fdt_create_empty_tree() in libfdt. */
>> >> +        return NULL;
>> >> +    }
>> >
>> >
>> > I don't think we currently support booting with no FDT at all, and even
>> > in the ACPI world we would get one. So I think this would be an error.
>> > IOW no need to worry about it.
>> >
>>
>> I think that for the ACPI-only case, the EFI stub will be the one
>> responsible for creating the FDT for passing the UEFI/ACPI to the XEN
>> kernel.  (I had overlooked the ACPI-only
>> case when considering the no-FDT case - for Linux we support this
>> since a kernel could be configured such that it needs nothing from the
>> FDT other than UEFI stuff, so we need to support it.)
>> So I think we will need this, but only for the ACPI-only case.
>
> I think you probably know better than I but I thought that the way the
> presence of ACPI was communicated to the kernel (whether via zImage or
> UEFI stub) was via entries in the FDT's /chosen/ node containing the
> address of the RSDP. Am I wrong about that?
>
> Or maybe I'm thinking about the UEFI services tables being referenced
> via /chosen/?
>
> Ian.
>
The ACPI tables are all referenced from the EFI system table, which is put
into the FDT by the EFI stub.  The EFI stub itself is completely ACPI agnostic -
it just passes along the EFI structures that may or may not contain ACPI tables.
The kernel will determine if ACPI support is present by looking for
the ACPI tables
in the EFI system table.

Roy

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel