On Thu, Sep 22, 2022 at 06:01:29PM +0100, Marc Zyngier wrote:
> In order to differenciate between architectures that require no extra
> synchronisation when accessing the dirty ring and those who do,
> add a new capability (KVM_CAP_DIRTY_LOG_RING_ORDERED) that identify
> the latter sort. TSO architectures can obviously advertise both, while
> relaxed architectures most only advertise the ORDERED version.
>
> Suggested-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
> ---
> include/linux/kvm_dirty_ring.h | 6 +++---
> include/uapi/linux/kvm.h | 1 +
> virt/kvm/Kconfig | 14 ++++++++++++++
> virt/kvm/Makefile.kvm | 2 +-
> virt/kvm/kvm_main.c | 11 +++++++++--
> 5 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/kvm_dirty_ring.h b/include/linux/kvm_dirty_ring.h
> index 906f899813dc..7a0c90ae9a3f 100644
> --- a/include/linux/kvm_dirty_ring.h
> +++ b/include/linux/kvm_dirty_ring.h
> @@ -27,7 +27,7 @@ struct kvm_dirty_ring {
> int index;
> };
>
> -#ifndef CONFIG_HAVE_KVM_DIRTY_RING
> +#ifndef CONFIG_HAVE_KVM_DIRTY_LOG
s/LOG/LOG_RING/ according to the commit message? Or the name seems too
generic.
Pure question to ask: is it required to have a new cap just for the
ordering? IIUC if x86 was the only supported anyway before, it means all
released old kvm binaries are always safe even without the strict
orderings. As long as we rework all the memory ordering bits before
declaring support of yet another arch, we're good. Or am I wrong?
Thanks,
--
Peter Xu
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
