Re: [RFC PATCH 4/9] hvm: Introduce "fixed memory layout" feature

["Teddy Astie" <teddy.astie@vates.tech>]

Le 28/08/2025 à 14:30, Jan Beulich a écrit :
> On 21.08.2025 17:25, Teddy Astie wrote:
>> @@ -686,10 +691,31 @@ static int domain_construct_memmap(libxl__gc *gc,
>>       /* We always own at least one lowmem entry. */
>>       unsigned int e820_entries = 1;
>>       struct e820entry *e820 = NULL;
>> +    uint64_t highmem_start = ((uint64_t)1 << 32);
>>       uint64_t highmem_size =
>>                       dom->highmem_end ? dom->highmem_end - (1ull << 32) : 0;
>>       uint32_t lowmem_start = dom->device_model ? GUEST_LOW_MEM_START_DEFAULT : 0;
>>       unsigned page_size = XC_DOM_PAGE_SIZE(dom);
>> +    /* Special region starts at the first 1G boundary after the highmem */
>> +    uint64_t special_region_start =
>> +        (highmem_start + highmem_size + GB(1) - 1) & ~(GB(1) - 1);
>
> That is, inaccessible before entering PAE mode?
>

Yes, I expect this to be only used by newer guests which hopefully
aren't limited to 4G range (i.e supports PAE or long mode). The issue of
trying to put that below 4G is that much of the space is already taken
for the MMIO hole, so that area would quite complicated with more
special regions.

> The open-coding of ROUNDUP() also isn't nice, but sadly unavoidable as long
> the the macro works in terms of unsigned long.
>
>> @@ -769,6 +805,40 @@ static int domain_construct_memmap(libxl__gc *gc,
>>           e820[nr].type = E820_RAM;
>>       }
>>
>> +    /* Special regions */
>> +    if (libxl_defbool_val(d_config->b_info.arch_x86.fixed_mem_layout))
>> +    {
>> +        e820[nr].type = XEN_HVM_MEMMAP_TYPE_SHARED_INFO;
>> +        e820[nr].addr = special_region_offset;
>> +        e820[nr].size = page_size;
>> +        special_region_offset += e820[nr].size;
>> +        nr++;
>> +
>> +        if ( gnttab_frame_count )
>> +        {
>> +            e820[nr].type = XEN_HVM_MEMMAP_TYPE_GRANT_TABLE;
>> +            e820[nr].addr = special_region_offset;
>> +            e820[nr].size = gnttab_frame_count * page_size;
>> +            special_region_offset += e820[nr].size;
>> +            nr++;
>> +        }
>> +
>> +        if (d_config->b_info.max_grant_version >= 2 && gnttab_status_frame_count)
>> +        {
>> +            e820[nr].type = XEN_HVM_MEMMAP_TYPE_GNTTAB_STATUS;
>> +            e820[nr].addr = special_region_offset;
>> +            e820[nr].size = gnttab_status_frame_count * page_size;
>> +            special_region_offset += e820[nr].size;
>> +            nr++;
>> +        }
>> +
>> +        e820[nr].type = XEN_HVM_MEMMAP_TYPE_FOREIGN_REG;
>> +        e820[nr].addr = special_region_offset;
>> +        e820[nr].size = MB(512);
>
> Can we really know this is going to be enough for all use cases?
>

Probably not, but we could make this area larger in the future without
changing this ABI.

>> --- a/xen/include/public/arch-x86/hvm/start_info.h
>> +++ b/xen/include/public/arch-x86/hvm/start_info.h
>> @@ -99,6 +99,13 @@
>>   #define XEN_HVM_MEMMAP_TYPE_DISABLED  6
>>   #define XEN_HVM_MEMMAP_TYPE_PMEM      7
>>
>> +/* Xen-specific types (OEM-specific range of the ACPI spec) */
>> +#define XEN_HVM_MEMMAP_TYPE_SHARED_INFO   0xF0000001 /* Shared info page */
>> +#define XEN_HVM_MEMMAP_TYPE_GRANT_TABLE   0xF0000002 /* Grant table pages */
>> +#define XEN_HVM_MEMMAP_TYPE_GNTTAB_STATUS 0xF0000003 /* Grant table status page (v2) */
>> +#define XEN_HVM_MEMMAP_TYPE_FOREIGN_REG   0xF0000004 /* Suitable region for grant mappings */
>> +                                                     /* and foreign mappings */
>
> I question it being legitimate for us to introduce new E820 types.
>

These E820 types are (at least in ACPI specification) in the OEM-defined
range which seems appropriate for me to use for Xen-specific mappings.

We could use reserved, but we still need a way to tell the OS what each
of these "reserved" regions actually means (or it is gonna be ignored).

> Jan
Teddy



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech