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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

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");

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