Re: [PATCH early-RFC 4/5] xen/arm: mm: Rework switch_ttbr()

[Julien Grall <julien@xxxxxxx>]

Hi Stefano,

On 14/03/2022 23:48, Stefano Stabellini wrote:
> > > - we save the current mapping
> > > - update it with the Xen 1:1
> > > - switch_ttbr
> > > - remove Xen 1:1
> > > - restore mapping
> > >
> > > It should work, right? Basically, a mapping conflict shouldn't be an
> > > issue given that the mapping has only to live long enough to call
> > > switch_ttbr_id.
> > Today switch_ttbr() is called before we initialized most of the memory layout.
> > So clashing with the VMAP and frametable is not a problem.
> >
> > However, the identity mapping may also clash with the region used to map Xen.
> > That said, technically, we are not able to handle Xen when its start address
> > is in region 2MB + 4K to 4MB (Xen is loaded at a 4KB aligned address).
> >
> > The trouble is some features (e.g. UBSAN, GCOV) can generate Xen image over
> > 2MB. IOW, the range where Xen cannot be loaded will increase.
> >
> > This is an issue because AFAIK, there is no away to tell GRUB "You can't load
> > Xen at this region". But even if there were one, I feel this restriction is
> > sort of random.
> >
> > I already wrote a patch to get rid of the restriction. The code is not too bad
> > (we only need an extra indirection). But I haven't sent it yet because it is
> > less critical with the re-shuffling of the memory layout.
> Interesting! I am curious: how did you manage to do it?
When the identity mapping is clashing with Xen runtime address, I am 
creating a temporary mapping for Xen at a different fixed address.
Once the MMU is turned on, we can jump to the temporary mapping. After 
that we are safe to remove the identity mapping and create the runtime 
Xen mapping. The last step is to jump on the runtime mapping and then 
remove the temporary mapping.
> For now and for this series the current approach and the 512GB limit are
> fine. My replies here are brainstorming to see if there are potential
> alternatives in the future in case the need arises.
On Arm64, we have 256TB worth of virtual address. So I think we can 
easily spare 512GB for the foreseeable :).
If we are at the point where we can't space 512GB, then we would need to 
have a more dynamic layout as I plan on arm32.
Xen would still be mapped at a specific virtual address so we don't need 
to update the relocations. But we could decide at runtime the position 
of other large mappings (e.g. vmap, domheap).
Probably the safest way is to link Xen at a very high address. It is 
quite unlikely that Xen will be loaded at such high address.
If it is, we could exceptionally relocate Xen (with this series it 
should be safer to do). That said, I would like to avoid relocating Xen 
until we see a use for that.
> I can see that a clash with Xen mapping could be problematic and the
> chances of that happening are low but non-zero. We could make sure that
> ImageBuilder always picks safe addresses and that would help but
> wouldn't remove the issue if someone is not using ImageBuilder.
AFAIU, ImageBuilder is here to cater U-boot users. I am not too worry 
about those setups because a user can pick any address they want. So as 
long as Xen print an error during the clash (already the case), the user 
can easily update their scripts.
This is more a problem for UEFI/GRUB where, AFAICT, we can't control 
where Xen will be loaded.
Cheers,

--
Julien Grall