On 15/09/2021 10:30, Jan Beulich wrote:
> On 14.09.2021 18:43, Kevin Stefanov wrote:
>> --- a/tools/libs/light/libxl_x86_acpi.c
>> +++ b/tools/libs/light/libxl_x86_acpi.c
>> @@ -20,6 +20,7 @@
>>
>> /* Number of pages holding ACPI tables */
>> #define NUM_ACPI_PAGES 16
>> +#define ALIGN(p, a) (
On 14.09.2021 18:43, Kevin Stefanov wrote:
> --- a/tools/libs/light/libxl_x86_acpi.c
> +++ b/tools/libs/light/libxl_x86_acpi.c
> @@ -20,6 +20,7 @@
>
> /* Number of pages holding ACPI tables */
> #define NUM_ACPI_PAGES 16
> +#define ALIGN(p, a) (((p) + ((a) - 1)) & ~((a) - 1))
Wouldn't this be
On 14/09/2021 17:43, Kevin Stefanov wrote:
> The memory allocator currently calculates alignment in libxl's virtual
> address space, rather than guest physical address space. This results
> in the FACS being commonly misaligned.
>
> Furthermore, the allocator has several other bugs.
>
> The opencod
The memory allocator currently calculates alignment in libxl's virtual
address space, rather than guest physical address space. This results
in the FACS being commonly misaligned.
Furthermore, the allocator has several other bugs.
The opencoded align-up calculation is currently susceptible to a b