On Thu, Sep 22, 2022 at 06:01:30PM +0100, Marc Zyngier wrote: > Since x86 is TSO (give or take), allow it to advertise the new > ORDERED version of the dirty ring capability. No other change is > required for it. > > Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx> > --- > arch/x86/kvm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig > index e3cbd7706136..eb63bc31ed1d 100644 > --- a/arch/x86/kvm/Kconfig > +++ b/arch/x86/kvm/Kconfig > @@ -29,6 +29,7 @@ config KVM > select HAVE_KVM_PFNCACHE > select HAVE_KVM_IRQFD > select HAVE_KVM_DIRTY_RING > + select HAVE_KVM_DIRTY_RING_ORDERED > select IRQ_BYPASS_MANAGER > select HAVE_KVM_IRQ_BYPASS > select HAVE_KVM_IRQ_ROUTING Before patch 2-3, we only have HAVE_KVM_DIRTY_RING. After that, we'll have: HAVE_KVM_DIRTY_LOG HAVE_KVM_DIRTY_RING HAVE_KVM_DIRTY_RING_ORDERED I'm wondering whether we can just keep using the old HAVE_KVM_DIRTY_RING, but just declare a new KVM_CAP_DIRTY_LOG_RING_ORDERED only after all memory barrier patches merged (after patch 1). IIUC it's a matter of whether any of the arch would like to support !ORDERED version of dirty ring at all, but then IIUC we'll need to have the memory barriers conditional too or not sure how it'll help. Thanks, -- Peter Xu _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
