Re: [Xen-devel] [PATCH v2 18/30] xen/x86: setup PVHv2 Dom0 ACPI tables

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 06/10/16 16:40, Jan Beulich wrote:
>>>> On 27.09.16 at 17:57, <roger.pau@xxxxxxxxxx> wrote:
>> FWIW, I think that the current approach that I've used in order to craft the
>> MADT is not the best one, IMHO it would be better to place the MADT at the
>> end of the E820_ACPI region (expanding it's size one page), and modify the
>> XSDT/RSDT in order to point to it, that way we avoid shadowing any other
>> ACPI data that might be at the same page as the native MADT (and that needs
>> to be modified by Dom0).
> I agree with the idea of placing MADT elsewhere, but I don't think you
> can rely on E820_ACPI to have room to grow into right after its end.
>
>> @@ -50,6 +53,8 @@ static long __initdata dom0_max_nrpages = LONG_MAX;
>>  #define HVM_VM86_TSS_SIZE   128
>>  
>>  static unsigned int __initdata hvm_mem_stats[MAX_ORDER + 1];
>> +static unsigned int __initdata acpi_intr_overrrides = 0;
>> +static struct acpi_madt_interrupt_override __initdata *intsrcovr = NULL;
> Pointless initializers.
>
>> +static void __init acpi_zap_table_signature(char *name)
>> +{
>> +    struct acpi_table_header *table;
>> +    acpi_status status;
>> +    union {
>> +        char str[ACPI_NAME_SIZE];
>> +        uint32_t bits;
>> +    } signature;
>> +    char tmp;
>> +    int i;
>> +
>> +    status = acpi_get_table(name, 0, &table);
>> +    if ( ACPI_SUCCESS(status) )
>> +    {
>> +        memcpy(&signature.str[0], &table->signature[0], ACPI_NAME_SIZE);
>> +        for ( i = 0; i < ACPI_NAME_SIZE / 2; i++ )
>> +        {
>> +            tmp = signature.str[ACPI_NAME_SIZE - i - 1];
>> +            signature.str[ACPI_NAME_SIZE - i - 1] = signature.str[i];
>> +            signature.str[i] = tmp;
>> +        }
>> +        write_atomic((uint32_t*)&table->signature[0], signature.bits);
>> +    }
>> +}
> Together with moving MADT elsewhere we should also move
> XSDT/RSDT, at which point we can simply avoid copying the
> pointers for tables we don't want Dom0 to see (and down the
> road we also have the option of adding tables).
>
> The downside to both approaches is that this once again is a
> black-listing model, i.e. new structure types we may need to
> also suppress will remain visible to Dom0 until a patched
> hypervisor would become available.

If we are providing a new XSDT/RSDT, we can have full control over the
tables dom0 sees.  Pointers to existing tables should only be entered
into the new XSDT/RSDT if Xen explicitly knows the table & version.

We will have to be diligent at keeping on top of new versions of the
ACPI spec, but everything like this should be whitelist based.  (This is
also the same model I trying to move the CPUID/MSR infrastructure towards).

~Andrew

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