Re: [PATCH v3 3/3] xen/riscv: introduce identity mapping

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.07.2023 18:35, Oleksii wrote:
> On Tue, 2023-07-18 at 17:03 +0200, Jan Beulich wrote:
>>> +            unsigned long load_end = LINK_TO_LOAD(_end);
>>> +            unsigned long pt_level_size = XEN_PT_LEVEL_SIZE(i -
>>> 1);
>>> +            unsigned long xen_size = ROUNDUP(load_end -
>>> load_start, pt_level_size);
>>> +            unsigned long page_entries_num = xen_size /
>>> pt_level_size;
>>> +
>>> +            while ( page_entries_num-- )
>>> +                pgtbl[index++].pte = 0;
>>> +
>>> +            break;
>>
>> Unless there's a "not crossing a 2Mb boundary" guarantee somewhere
>> that I've missed, this "break" is still too early afaict.
> If I will add a '2 MB boundary check' for load_start and linker_start
> could it be an upstreamable solution?
> 
> Something like:
>     if ( !IS_ALIGNED(load_start, MB(2) )
>       printk("load_start should be 2Mb algined\n");
> and
>     ASSERT( !IS_ALIGNED(XEN_VIRT_START, MB(2) )
> in xen.lds.S.

Arranging for the linked address to be 2Mb-aligned is certainly
reasonable. Whether expecting the load address to also be depends
on whether that can be arranged for (which in turn depends on boot
loader behavior); it cannot be left to "luck".

> Then we will have completely different L0 tables for identity mapping
> and not identity and the code above will be correct.

As long as Xen won't grow beyond 2Mb total. Considering that at
some point you may want to use large page mappings for .text,
.data, and .rodata, that alone would grow Xen to 6 Mb (or really 8,
assuming .init goes separate as well). That's leaving aside the
realistic option of the mere sum of all sections being larger than
2. That said, even Arm64 with ACPI is still quite a bit below 2Mb.
x86 is nearing 2.5 though in even a somewhat limited config;
allyesconfig may well be beyond that already.

Of course you may legitimately leave dealing with that to the
future.

Jan