Re: [PATCH 00/12] Arm cache coloring

[Julien Grall <julien@xxxxxxx>]

Hi Carlo,

On 26/08/2022 13:50, Carlo Nonato wrote:
> - The way xl passes user space memory to Xen it's adapted from various
>    points of the xl code itself (e.g. xc_domain_node_setaffinity) and it
>    works, but it really needs attention from expert maintainers since
>    I'm not completely sure this is the correct way of doing things.
> - We still need to bring back the relocation feature (part of) in order
>    to move Xen memory to a colored space where the hypervisor could be
>    isolated from VMs interference (see the revert commit #10 and the
>    get_xen_paddr function in #12).
> - Revert commits #8 and #9 are needed because coloring has the command
>    line parsing as a prerequisite for its initialization and
>    setup_pagetables must be called after it in order to color the Xen
>    mapping. The DTB mapping is then added to the boot page tables instead
>    of the Xen ones. Probably the way this is done is a bit simplistic.
>    Looking forward for comments on the subject.
> - A temporary mapping of the old Xen code (old here means non-colored)
>    is used to reach variables in the old physical space so that secondary
>    CPUs can boot. There were some comments in the previous version on that
>    because the mapping is available for all the CPUs while only CPU0 is
>    the one supposed to access it. I'm not sure how to temporarily mapping
>    things only for the master CPU.
On Arm64, Xen will only use one set of page-tables for all the CPUs. So 
it will not be possible to have a temporary mapping for a single CPU. 
But what you can do is mapping the region and unmapping it when you are 
done.
That said, I would rather prefer if we can get rid of the old copy of 
Xen. This would means secondary CPUs will directly jump to the new Xen.
> - A lot of #ifdef for cache coloring are introduced because I prefer to
>    define functions only if they are actually needed. Let me know if you
>    prefer a different approach.
The preferred approach in Xen is to provide stub helpers in the #else part.

> - Julien posted an RFC to address a problem with the switch_ttbr function.
>    For the moment I haven't considered it since it's still a work in progress.
I have posted a new version for this:

https://lore.kernel.org/xen-devel/20221022150422.17707-1-julien@xxxxxxx/

There are a couple of open questions about the interaction with cache 
coloring. Please have a look there.
Cheers,

--
Julien Grall