Re: [Xen-devel] [PATCH RFC 10/20] acpi/hvmloader: Provide address of acpi_info as an argument to ACPI code

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.04.16 at 03:25, <boris.ostrovsky@xxxxxxxxxx> wrote:
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
> @@ -306,6 +306,9 @@ struct acpi_20_waet {
>  
>  #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
>  
> +/* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! 
> */
> +#define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000UL

As said in the context of another patch - I don't think this belongs
here, the more that the consumer is in hvmloader/util.c. This is
genuinely a decision of the rest of the firmware (i.e. hvmloader
here). Plus, even if it was to be determined by libacpi, this would
be the wrong header- here there are supposed to be only ACPI
interface definitions.

The same then of course applies to ACPI_TIS_HDR_ADDRESS.

> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -65,8 +65,7 @@ extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
>  #define HVMLOADER_PHYSICAL_ADDRESS    0x00100000
>  /* Special BIOS mappings, etc. are allocated from here upwards... */
>  #define RESERVED_MEMBASE              0xFC000000
> -/* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! 
> */
> -#define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000
> +
>  #define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
>  #define RESERVED_MEMORY_DYNAMIC_END   0xFE000000

The lower context here actually supports what I've said above. So
I think that itsem should stay here.

Jan


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