On Tue, Mar 15, 2022 at 06:23:53PM +0000, James Morse wrote:
Hi Greg,
Here is the state of the current v5.4 backport. Now that the 32bit
code has been merged, it doesn't conflict when KVM's shared 32bit/64bit
code needs to use these constants.
I've fixed the two issues that were reported against the v5.10 backport.
I had a go at bringing all the pre-requisites in to add proton-pack.c
to v5.4. Its currently 39 patches:
https://git.gitlab.arm.com/linux-arm/linux-jm.git /bhb/alternative_backport/UNTESTED/v5.4.183
(or for web browsers:
https://gitlab.arm.com/linux-arm/linux-jm/-/commits/bhb/alternative_backport/UNTESTED/v5.4.183/
)
I've queued it up.
I've not managed to bring b881cdce77b4 "KVM: arm64: Allocate hyp vectors
statically" in, as that depends on the hypervisor's per-cpu support. Its
this patch that means those 'smccc_wa' templates are needed.
I estimate it would be 60 patches in total if we go this way, I don't
think its a good idea:
All this still has to work around 541ad0150ca4 ("arm: Remove 32bit KVM
host support") and 9ed24f4b712b ("KVM: arm64: Move virt/kvm/arm to
arch/arm64") being missing.
I think this approach creates more problems than it solves as the
files have to be in different places because of 32bit. It also creates
a significantly larger testing problem: I'm not looking forward to
working out how to test KVM guest migration over the variant-4 KVM ABI
changes in 29e8910a566a.
I think that the workaround you mention later on for this issue makes
sense cost/benefit-wise.
This version of the backport still adds the mitigation management code
to cpu_errata.c, because that is where this stuff lived in v5.4.
If you prefer, I can try adding proton-pack.c as a new empty file.
I think this would only confuse matters as the line-numbers would
never match, and there is an interaction with the spectre-v2 mitigations
that live in cpu_errata.c.
There is one patch not present in mainline 'KVM: arm64: Add templtes for
BHB mitigation sequences'.
Thank you!
--
Thanks,
Sasha
