qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 5/5] hw/arm/virt-acpi-build: Generate SRAT ta


From: Shannon Zhao
Subject: Re: [Qemu-devel] [PATCH v5 5/5] hw/arm/virt-acpi-build: Generate SRAT table
Date: Sat, 23 Apr 2016 09:08:52 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0


On 2016/4/22 21:26, Andrew Jones wrote:
>> +        core->flags = cpu_to_le32(1);
>> > +    }
>> > +    g_free(cpu_node);
>> > +
>> > +    mem_base = guest_info->memmap[VIRT_MEM].base;
>> > +    for (i = 0; i < nb_numa_nodes; ++i) {
>> > +        mem_len = numa_info[i].node_mem;
>> > +        numamem = acpi_data_push(table_data, sizeof *numamem);
>> > +        numamem->type = ACPI_SRAT_MEMORY;
>> > +        numamem->length = sizeof(*numamem);
>> > +        memset(numamem->proximity, 0, 4);
>> > +        numamem->proximity[0] = i;
> This is weird (but I see x86 does it too). The spec says proximity is
> "Integer that represents the proximity domain to which the processor
>  belongs", and its 4 bytes. So why doesn't the structure define it as
> a uint32_t and then we'd just do
> 
>   numamem->proximity = cpu_to_le32(i);
> 
> (adding Igor)
> 
>> > +        numamem->flags = cpu_to_le32(1);
>> > +        numamem->base_addr = cpu_to_le64(mem_base);
>> > +        numamem->range_length = cpu_to_le64(mem_len);
> How about moving acpi_build_srat_memory from hw/i386/acpi-build.c to
> somewhere in hw/acpi and reusing it?
> 
Good point! Will do that.

Thanks,
-- 
Shannon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]