On Thu, Jul 15, 2021 at 05:31:49PM +0100, Marc Zyngier wrote:
> As we now keep information in the S2PT, we must be careful not
> to keep it across a VM reboot, which could otherwise lead to
> interesting problems.
>
> Make sure that the S2 is completely discarded on reset of
> a vcpu, and remove the flag that enforces the MMIO check.
>
> Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
> ---
> arch/arm64/kvm/arm.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 97ab1512c44f..b0d2225190d2 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1096,12 +1096,18 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
> * ensuring that the data side is always coherent. We still
> * need to invalidate the I-cache though, as FWB does *not*
> * imply CTR_EL0.DIC.
> + *
> + * If the MMIO guard was enabled, we pay the price of a full
> + * unmap to get back to a sane state (and clear the flag).
> */
> if (vcpu->arch.has_run_once) {
> - if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB))
> + if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB) ||
> + test_bit(KVM_ARCH_FLAG_MMIO_GUARD, &vcpu->kvm->arch.flags))
> stage2_unmap_vm(vcpu->kvm);
> else
> icache_inval_all_pou();
> +
> + clear_bit(KVM_ARCH_FLAG_MMIO_GUARD, &vcpu->kvm->arch.flags);
What prevents this racing with another vCPU trying to set the bit?
Will
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
