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
