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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

>>> 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.

Oh well.

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

If you want me to ack such, the limitations will need clearly calling out
as such (and why it needs doing like this). Further the public interface
wants leaving as tidy as possible, as removing stuff from there is
usually not a straightforward thing to do. Ideally, no part of this would
be encoded into the public headers, if at all possible.

You also may recall that I have reservations towards this work targeting
dom0less alone. Yet that's likely okay(ish) as long as this is the mutual
understanding of interested parties (and again clearly expressed in
relevant places).

Jan