On Sat, 24 Sep 2022 14:22:32 +0100, Peter Xu <peterx@xxxxxxxxxx> wrote: > > On Sat, Sep 24, 2022 at 12:26:53PM +0100, Marc Zyngier wrote: > > On Sat, 24 Sep 2022 09:51:39 +0100, > > Marc Zyngier <maz@xxxxxxxxxx> wrote: > > > > > > I'm happy to bikeshed, but please spell it out for me. If we follow > > > the current scheme, we need 3 configuration symbols (of which we > > > already have one), and 2 capabilities (of which we already have one). > > I hope it's not bikeshedding. I normally don't comment on namings at all > because many of them can be "bikeshedding" to me. But this one is so > special because it directly collides with KVM_GET_DIRTY_LOG, which is other > method of dirty tracking. Fair enough. I'm notoriously bad at sticking a name to things, so I'm always happy to receive suggestions. > > > > > > > Do you have any concrete proposal for those? > > > > In order to make some forward progress, I've reworked the series[1] > > with another proposal for those: > > > > Config symbols: > > > > - HAVE_KVM_DIRTY_RING: > > * mostly the same meaning as today > > * not directly selected by any architecture > > * doesn't expose any capability on its own > > > > - HAVE_KVM_DIRTY_RING_TSO: > > * only for strongly ordered architectures > > * selects HAVE_KVM_DIRTY_RING > > * exposes KVM_CAP_DIRTY_LOG_RING > > * selected by x86 > > > > - HAVE_KVM_DIRTY_RING_ACQ_REL: > > * selects HAVE_KVM_DIRTY_RING > > * exposes KVM_CAP_DIRTY_LOG_RING_ACQ_REL > > * selected by arm64 and x86 > > > > Capabilities: > > > > - KVM_CAP_DIRTY_LOG_RING: the good old x86-specific stuff, advertised > > when HAVE_KVM_DIRTY_RING_TSO is selected > > > > - KVM_CAP_DIRTY_LOG_RING_ACQ_REL: the new acquire/release semantics, > > advertised when HAVE_KVM_DIRTY_RING_ACQ_REL is selected > > > > This significantly reduces the churn and makes things slightly more > > explicit. > > This looks good to me, thanks. OK, thanks for having a quick look. I'll repost this shortly, after I'm done reviewing Gavin's series. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
