On 4/1/25 1:59 PM, Julien Grall wrote:
On 01/04/2025 07:24, Jan Beulich wrote:
On 31.03.2025 18:17, Julien Grall wrote:
On 31/03/2025 17:14, Jan Beulich wrote:
On 31.03.2025 17:20, Oleksii Kurochko wrote:
A randconfig job failed with the following issue:
riscv64-linux-gnu-ld: Xen too large for early-boot assumptions
The reason is that enabling the UBSAN config increased the size of
the Xen binary.
Increase XEN_VIRT_SIZE to reserve enough space, allowing both UBSAN
and GCOV to be enabled together, with some slack for future growth.
At some point you may want to use 2M mappings for .text (rx), .rodata
(r), and .data (rw).
OOI, why would we want to switch to 2MB? At least on Arm, Xen is tiny
enough that it can fit in less than a couple of MB. I would expect the
same for RISC-V.
For TLB efficiency reasons for example. On x86 we switched to using 2Mb
pages quite some time back, just to find that (at least) one of the
bootloaders choked on the then larger binary. Hence we ended up with
the XEN_ALIGN_2M Kconfig symbol plus the unconditional use of 2Mb
mappings for xen.efi. For the original change see cf393624eec3 ("x86:
use 2M superpages for text/data/bss mappings").
For Arm, we can using the contiguous bit (it allows to combine a few
entries into one TLB on some CPUs) to reduce the TLB usage. Not sure
if RISC-V has a similar feature.
Unfortunately, RISC-V doesn't have such option.
~ Oleksii
