Re: [PATCH 2/6] KVM: Add KVM_CAP_DIRTY_LOG_RING_ORDERED capability and config option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 23 Sep 2022 19:26:18 +0100,
Peter Xu <peterx@xxxxxxxxxx> wrote:
> 
> On Fri, Sep 23, 2022 at 03:28:34PM +0100, Marc Zyngier wrote:
> > On Thu, 22 Sep 2022 22:48:19 +0100,
> > Peter Xu <peterx@xxxxxxxxxx> wrote:
> > > 
> > > 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.
> > 
> > The commit message talks about the capability, while the above is the
> > config option. If you find the names inappropriate, feel free to
> > suggest alternatives (for all I care, they could be called FOO, BAR
> > and BAZ).
> 
> The existing name from David looks better than the new one.. to me.

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).

Do you have any concrete proposal for those?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux