[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 4/5] xen: Add files needed for minimal riscv build
On 5/14/21 4:47 PM, Connor Davis wrote: > > On 5/14/21 3:53 PM, Bob Eshleman wrote: >> On 5/14/21 11:53 AM, Connor Davis wrote: >> >>> + >>> +#ifdef CONFIG_RISCV_64 >>> + >>> +/* >>> + * RISC-V Layout: >>> + * 0x0000000000000000 - 0x0000003fffffffff (256GB, L2 slots [0-255]) >>> + * Unmapped >>> + * 0x0000004000000000 - 0xffffffbfffffffff >>> + * Inaccessible: sv39 only supports 39-bit sign-extended VAs. >>> + * 0xffffffc000000000 - 0xffffffc0001fffff (2MB, L2 slot [256]) >>> + * Unmapped >>> + * 0xffffffc000200000 - 0xffffffc0003fffff (2MB, L2 slot [256]) >>> + * Xen text, data, bss >>> + * 0xffffffc000400000 - 0xffffffc0005fffff (2MB, L2 slot [256]) >>> + * Fixmap: special-purpose 4K mapping slots >>> + * 0xffffffc000600000 - 0xffffffc0009fffff (4MB, L2 slot [256]) >>> + * Early boot mapping of FDT >>> + * 0xffffffc000a00000 - 0xffffffc000bfffff (2MB, L2 slot [256]) >>> + * Early relocation address, used when relocating Xen and later >>> + * for livepatch vmap (if compiled in) >>> + * 0xffffffc040000000 - 0xffffffc07fffffff (1GB, L2 slot [257]) >>> + * VMAP: ioremap and early_ioremap >>> + * 0xffffffc080000000 - 0xffffffc13fffffff (3GB, L2 slots [258..260]) >>> + * Unmapped >>> + * 0xffffffc140000000 - 0xffffffc1bfffffff (2GB, L2 slots [261..262]) >>> + * Frametable: 48 bytes per page for 133GB of RAM >>> + * 0xffffffc1c0000000 - 0xffffffe1bfffffff (128GB, L2 slots [263..390]) >>> + * 1:1 direct mapping of RAM >>> + * 0xffffffe1c0000000 - 0xffffffffffffffff (121GB, L2 slots [391..511]) >>> + * Unmapped >>> + */ >>> + >> What is the benefit of moving the layout up to 0xffffffc000000000? > > I thought it made the most sense to use the upper half since Xen is privileged > > and privileged code is typically mapped in the upper half, at least on x86. > I'm happy to > > move it down if that would be preferred. > > I do like the idea of following norms, but I think I prefer following the ARM norm over the x86 norm unless there is a technical reason not to. Just due to ARM and RISC-V having much more overlap than x86 and RISC-V. In this case, all things being equal, I'd prefer following the ARM model and use the lower half. I definitely like adding the note on the inaccessible region. Thanks, -- Bobby Eshleman SE at Vates SAS
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |