Re: [PATCH v1] xen/riscv: Increase XEN_VIRT_SIZE

[Oleksii Kurochko <oleksii.kurochko@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]


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

[-- Attachment #2: Type: text/html, Size: 2779 bytes --]