summaryrefslogtreecommitdiff
path: root/scripts/lib/kdoc/kdoc_files.py
diff options
context:
space:
mode:
authorMarc Zyngier <maz@kernel.org>2025-07-01 16:16:47 +0100
committerOliver Upton <oliver.upton@linux.dev>2025-07-23 23:34:50 -0700
commita508d5afb70894ab50ccc4678f55ff801468182b (patch)
tree93f24018b930b87dfbfa92de420e99f68269569d /scripts/lib/kdoc/kdoc_files.py
parent4530256f3699a053f0b9dc677e231d570bbd0eea (diff)
KVM: arm64: Remove the wi->{e0,}poe vs wr->{p,u}ov confusion
Some of the POE computation is a bit confused. Specifically, there is an element of confusion between what wi->{e0,}poe an wr->{p,u}ov actually represent. - wi->{e0,}poe is an *input* to the walk, and indicates whether POE is enabled at EL0 or EL{1,2} - wr->{p,u}ov is a *result* of the walk, and indicates whether overlays are enabled. Crutially, it is possible to have POE enabled, and yet overlays disabled, while the converse isn't true What this all means is that once the base permissions have been established, checking for wi->{e0,}poe makes little sense, because the truth about overlays resides in wr->{p,u}ov. So constructs checking for (wi->poe && wr->pov) only add perplexity. Refactor compute_s1_overlay_permissions() and the way it is called according to the above principles. Take the opportunity to avoid reading registers that are not strictly required. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250701151648.754785-2-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Diffstat (limited to 'scripts/lib/kdoc/kdoc_files.py')
0 files changed, 0 insertions, 0 deletions