Re: [PATCH v2 10/11] xen/riscv: add definition of guest RAM banks

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.04.2026 10:54, Oleksii Kurochko wrote:
> 
> 
> On 4/7/26 8:23 AM, Jan Beulich wrote:
>> On 06.04.2026 17:43, Oleksii Kurochko wrote:
>>>
>>>
>>> On 4/1/26 5:10 PM, Jan Beulich wrote:
>>>> On 01.04.2026 16:53, Oleksii Kurochko wrote:
>>>>>
>>>>>
>>>>> On 4/1/26 4:22 PM, Jan Beulich wrote:
>>>>>> On 01.04.2026 15:57, Oleksii Kurochko wrote:
>>>>>>> On 4/1/26 8:17 AM, Jan Beulich wrote:
>>>>>>>> On 31.03.2026 18:14, Oleksii Kurochko wrote:
>>>>>>>>> On 3/30/26 5:51 PM, Jan Beulich wrote:
>>>>>>>>>> On 23.03.2026 17:29, Oleksii Kurochko wrote:
>>>>>>>>>>> The dom0less solution uses defined RAM banks as compile-time 
>>>>>>>>>>> constants,
>>>>>>>>>>> so introduce macros to describe guest RAM banks.
>>>>>>>>>>>
>>>>>>>>>>> The reason for 2 banks is that there is typically always a use case 
>>>>>>>>>>> for
>>>>>>>>>>> low memory under 4 GB, but the bank under 4 GB ends up being small 
>>>>>>>>>>> because
>>>>>>>>>>> there are other things under 4 GB it can conflict with (interrupt
>>>>>>>>>>> controller, PCI BARs, etc.).
>>>>>>>>>> Fixed layouts like the one you suggest come with (potentially severe)
>>>>>>>>>> downsides. For example, what if more than 2Gb of MMIO space are 
>>>>>>>>>> needed
>>>>>>>>>> for non-64-bit BARs?
>>>>>>>>> It looks where usually RAM on RISC-V boards start, so I expect that 
>>>>>>>>> 2gb
>>>>>>>>> before RAM start is enough for MMIO space.
>>>>>>>> Likely in the common case. Board designers aren't constrained by this,
>>>>>>>> though (aiui). Whereas you set in stone a single, fixed layout.
>>>>>>>>
>>>>>>>> Arm maintainers - since a similar fixed layout is used there iirc,
>>>>>>>> could you chime in here, please?
>>>>>>>>
>>>>>>>>> Answering your question it will be an issue or it will also use some
>>>>>>>>> space before banks, no?
>>>>>>>> I fear I don't understand what you're trying to tell me.
>>>>>>> I meant that there is also some space between banks and pretty big which
>>>>>>> could be used for MMIO which could be used for non-64-bit BARs.
>>>>>> I don't follow: Bank 0 extends to 4G. There's no space above it, below
>>>>>> bank 1, which could be use for non-64-bit BARs.
>>>>>
>>>>> So we have two banks:
>>>>> bank[0] -> [0x80000000, 0x100000000)
>>>>> bank[1] -> [0x0200000000, 10000000000)
>>>>>
>>>>> So i think we have some space between them [0x100000000, 0x0200000000)
>>>>> -> 4gb to be used for non-64-bit BARs.
>>>>
>>>> But a non-64-bit BAR need to be assigned an address below 0x100000000?
>>>
>>> Right, I had in mind that RV32 uses for guest Sv32x4 which could
>>> translate 34-bit GPA into 34-bit MPA and automatically applied that to
>>> 32-bit BAR...
>>>
>>> I can keep first 4gb for MMIO purpose and start bank[0] at 4gb as 34 MPA
>>> address space is more then enough to cover reserved 2gb of bank[0] after
>>> 4gb.
>>
>> Yet having no memory below 4G won't work for guests wanting to run in bare
>> mode? Don't guests even start up in bare mode (and hence 32-bit ones need
>> to have some of their memory below 4G in all cases)?
> 
> I thought about such use case but decided that no one will want to run 
> guest in bare mode and that is why we have:
>      if ( max_gstage_mode.mode == HGATP_MODE_OFF )
>          panic("Xen expects that G-stage won't be Bare mode\n");

How does HGATP matter here? We're talking of guest physical address space
layout, and hence it's SATP which matters.

> Probably it is wrong assumption and we really want to support Bare mode 
> for guest too. Let me know if I have to drop the panic above...
> 
> Then it isn't clear what will be the best layout for the current 
> limitation that guest RAM should be compile-time constant for dom0less 
> solution.
> It looks to me that giving 2gb reserved for MMIO and 2gb for guest RAM 
> is fair enough.
> As an option 3gb for MMIO and 1gb for guest RAM will be enough as only 
> Bare model will have such small amount of RAM, for other modes part of 
> bank[1] could be used.

All of which only supports my take that you don't want to make guest
memory layout an ABI property. Using compile-time determined banks for
now may be okay(ish), but in the longer run things will want determining
dynamically (or specifying via per-guest config).

Jan