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

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

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.

> 
>> Further, assuming that the space 4G...8G is what
>>> you expect 64-bit BARs to be put into, what if there's a device with a
>>> 4G BAR? It'll eat up that entire space, requiring everything else to
>>> fit in the 2G you reserve below 4G.
>> I assume that such big devices could use high memory without any issue.
> Well, I could go (almost) arbitrarily low with individual BAR size,
> merely increasing the number of BARs accordingly. Assuming 2G BARs are
> 64-bit capable is likely fine. Maybe the same is true for 1G and 512M
> ones as well. Yet a some size the assumption will break.
> 
> IMO RAM layout wants establishing dynamically based on the MMIO needs
> of a guest.

I have this in my TODO.

But with the current implementation of dom0less it requires to have RAM 
banks defined in compile time.

Can we process with the current suggested way with the following update 
of dom0less code to work with dynamically allocated RAM layout?

~ Oleksii