Re: [PATCH v4 25/25] xen/riscv: add initial dom0less infrastructure support

[Oleksii Kurochko <oleksii.kurochko@gmail.com>]

On 7/2/26 8:41 AM, Jan Beulich wrote:
> On 01.07.2026 17:24, Oleksii Kurochko wrote:
>> On 6/30/26 9:28 AM, Jan Beulich wrote:
>>> On 26.06.2026 17:46, Oleksii Kurochko wrote:
>>>> --- a/xen/arch/riscv/include/asm/guest-layout.h
>>>> +++ b/xen/arch/riscv/include/asm/guest-layout.h
>>>> @@ -32,4 +32,16 @@
>>>>    #define GUEST_RAM_BANK_BASES   { GUEST_RAM0_BASE, GUEST_RAM1_BASE }
>>>>    #define GUEST_RAM_BANK_SIZES   { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE }
>>>>    
>>>> +/*
>>>> + * The guest magic region holds Xen-reserved pages mapped into the guest's
>>>> + * physical address space (shared info, grant table, etc.). The only real
>>>> + * constraint is that the GUEST_MAGIC_SIZE-byte region must not overlap
>>>> + * guest RAM (the GUEST_RAMx banks) or the emulated device regions defined
>>>> + * above; the exact base is otherwise arbitrary. Here it is placed in the
>>>> + * unused gap below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM
>>>> + * bank would work equally well.
>>>> + */
>>>> +#define GUEST_MAGIC_BASE  _UL(0x79000000)
>>>> +#define GUEST_MAGIC_SIZE  _UL(0x01000000)
>>>
>>> ... while 16Mb may seem a lot, it feels pretty little for 64-bit guests.
>>> Even in just Sv39 mode they have ample VA space to map a bigger region.
>>> (As iirc indicated before, a static upper bound looks questionable to me
>>> anyway.)
>>
>> I think the comment should be updated as for grants will be separate region.
>>
>> For all others, it looks like 16MB is more then enough. For example, Arm
>> has only 4 used pages (CONSOLE=0, XENSTORE=1, MEMACCESS=2, VUART=3).
> 
> Then the question goes the other way around: Why 16Mb? Won't e.g. 2Mb
> suffice?

I don't see any technical reason to have 16 Mb on Arm, IMO it could be 
shrunk to what you suggested (I will do that for RISC-V).

~ Oleksii

> 
>> So will you be okay with reworking of the comment to:
>> /*
>>    * The guest magic region holds the Xen-reserved pages mapped into the
>>    * guest's physical address space. The only real constraint on
>>    * GUEST_MAGIC_BASE/SIZE is that the region must not overlap guest RAM
>>    * (the GUEST_RAMx banks) or the emulated device regions defined above;
>>    * the exact base is otherwise arbitrary. Here it is placed in the
>> unused gap
>>    * below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM bank
>> would work
>>    * equally well.
>>    */
>>
>> And add to the commit message that:
>> ```
>> A separate region for grant tables will be introduced at the same time
>> as the introduction of the grant table for RISC-V.
>> ```
> 
> That's quite a bit better, yes.
> 
> Jan