|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 10/11] xen/riscv: add definition of guest RAM banks
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. And also we have another 2gb before bank[0]. ~ Oleksii
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |