Hi,
On Tue, Sep 20, 2022 at 10:58:15AM +0200, Andrew Jones wrote:
> On Tue, Aug 09, 2022 at 10:15:46AM +0100, Alexandru Elisei wrote:
> > phys_end was used to cap the linearly mapped memory to 3G to allow 1G of
> > room for the vmalloc area to grown down. This was made useless in commit
> > c1cd1a2bed69 ("arm/arm64: mmu: Remove memory layout assumptions"), when
> > setup_mmu() was changed to map all the detected memory regions without
> > changing their limits.
>
> c1cd1a2bed69 was a start, but as that commit says, the 3G-4G region was
> still necessary due to assumptions in the virtual memory allocator. This
> patch needs to point out a vmalloc commit which removes that assumption
> as well for its justification.
By "made useless" I mean that after that commit phys_end has no influence
on the way setup_mmu() creates the translation tables.
Yes, it's a problem because on real hardware or with kvmtool, which allows
the user to specify where RAM starts, the test can be loaded at the same
address from where vmalloc() will start allocating memory. But I think that
should be fixed separately from this series, maybe as part of the main
UEFI series, or as a separate patch(es).
I'll drop this patch, and leave any cleanups for when the vmalloc area
change is implemented.
Thanks,
Alex
>
> Thanks,
> drew
>
> >
> > Signed-off-by: Alexandru Elisei <alexandru.elisei@xxxxxxx>
> > ---
> > lib/arm/mmu.c | 6 +-----
> > 1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/lib/arm/mmu.c b/lib/arm/mmu.c
> > index e1a72fe4941f..8f936acafe8b 100644
> > --- a/lib/arm/mmu.c
> > +++ b/lib/arm/mmu.c
> > @@ -153,14 +153,10 @@ void mmu_set_range_sect(pgd_t *pgtable, uintptr_t virt_offset,
> > }
> > }
> >
> > -void *setup_mmu(phys_addr_t phys_end, void *unused)
> > +void *setup_mmu(phys_addr_t unused0, void *unused1)
> > {
> > struct mem_region *r;
> >
> > - /* 3G-4G region is reserved for vmalloc, cap phys_end at 3G */
> > - if (phys_end > (3ul << 30))
> > - phys_end = 3ul << 30;
> > -
> > #ifdef __aarch64__
> > init_alloc_vpage((void*)(4ul << 30));
> >
> > --
> > 2.37.1
> >
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
