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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 4/7/26 11:09 AM, Jan Beulich wrote:
> 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.
oh, right, it is hgatp.

> > 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).
I've already planned to move it to some arch specific header instead of 
ABI header.
Thanks.

~ Oleksii