[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 05/62] acpi: Don't do traditional BIOS table scan for ARM64



>>> On 24.11.15 at 04:39, <zhaoshenglong@xxxxxxxxxx> wrote:
> On 2015/11/23 19:35, Jan Beulich wrote:
>>>>> On 23.11.15 at 12:24, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>>> On Tue, 17 Nov 2015, shannon.zhao@xxxxxxxxxx wrote:
>>>> --- a/xen/drivers/acpi/osl.c
>>>> +++ b/xen/drivers/acpi/osl.c
>>>> @@ -78,7 +78,9 @@ acpi_physical_address __init 
>>>> acpi_os_get_root_pointer(void)
>>>>    } else {
>>>>            acpi_physical_address pa = 0;
>>>>  
>>>> +          #ifdef CONFIG_X86
>>>>            acpi_find_root_pointer(&pa);
>>>> +          #endif
>>>>            return pa;
>>>>    }
>>>
>>> I think it might be best to error out earlier if acpi and !efi_enabled
>>> on arm and arm64.  If we do that we'll never enter this "else".
>>>
>>> If acpi_find_root_pointer doesn't build on arm, we should move it to an
>>> x86 specific location, such as xen/arch/x86/efi.
>> 
>> No, definitely not (or if anything, then xen/arch/x86/acpi/). Instead
>> the function itself should be stubbed out to do nothing on ARM. (And
>> of course also the #ifdef placement is rather odd).
>> 
> How about adding a new CONFIG_ACPI_LEGACY_TABLES_LOOKUP like Linux
> kernel for x86?

Unless you know of an architecture other than x86 potentially
needing this, I think this would go too far. Plus the suggested name
would imply "old style" lookup only, whereas per-arch customization
also allows for other "modern" (or simply "alternative") mechanisms
to be used.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.