All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Peter Xu <peterx@redhat.com>
Cc: kvm@vger.kernel.org, catalin.marinas@arm.com,
	andrew.jones@linux.dev, will@kernel.org, shan.gavin@gmail.com,
	bgardon@google.com, dmatlack@google.com, pbonzini@redhat.com,
	zhenyzha@redhat.com, shuah@kernel.org,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 2/6] KVM: Add KVM_CAP_DIRTY_LOG_RING_ORDERED capability and config option
Date: Sat, 24 Sep 2022 19:57:49 +0100	[thread overview]
Message-ID: <878rm8ior6.wl-maz@kernel.org> (raw)
In-Reply-To: <Yy8EmMhF+2jcm3m6@x1n>

On Sat, 24 Sep 2022 14:22:32 +0100,
Peter Xu <peterx@redhat.com> 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@kernel.org> 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@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Peter Xu <peterx@redhat.com>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	catalin.marinas@arm.com, bgardon@google.com, shuah@kernel.org,
	andrew.jones@linux.dev, will@kernel.org, dmatlack@google.com,
	pbonzini@redhat.com, zhenyzha@redhat.com, shan.gavin@gmail.com,
	gshan@redhat.com, James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>
Subject: Re: [PATCH 2/6] KVM: Add KVM_CAP_DIRTY_LOG_RING_ORDERED capability and config option
Date: Sat, 24 Sep 2022 19:57:49 +0100	[thread overview]
Message-ID: <878rm8ior6.wl-maz@kernel.org> (raw)
In-Reply-To: <Yy8EmMhF+2jcm3m6@x1n>

On Sat, 24 Sep 2022 14:22:32 +0100,
Peter Xu <peterx@redhat.com> 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@kernel.org> 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.

  reply	other threads:[~2022-09-24 18:58 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22 17:01 [PATCH 0/6] KVM: Fix dirty-ring ordering on weakly ordered architectures Marc Zyngier
2022-09-22 17:01 ` Marc Zyngier
2022-09-22 17:01 ` [PATCH 1/6] KVM: Use acquire/release semantics when accessing dirty ring GFN state Marc Zyngier
2022-09-22 17:01   ` Marc Zyngier
2022-09-22 21:38   ` Peter Xu
2022-09-22 21:38     ` Peter Xu
2022-09-22 23:46     ` Gavin Shan
2022-09-22 23:46       ` Gavin Shan
2022-09-23 14:40       ` Marc Zyngier
2022-09-23 14:40         ` Marc Zyngier
2022-09-23 14:19     ` Marc Zyngier
2022-09-23 14:19       ` Marc Zyngier
2022-09-23 14:22       ` Paolo Bonzini
2022-09-23 14:22         ` Paolo Bonzini
2022-09-22 17:01 ` [PATCH 2/6] KVM: Add KVM_CAP_DIRTY_LOG_RING_ORDERED capability and config option Marc Zyngier
2022-09-22 17:01   ` Marc Zyngier
2022-09-22 21:48   ` Peter Xu
2022-09-22 21:48     ` Peter Xu
2022-09-23  0:04     ` Gavin Shan
2022-09-23  0:04       ` Gavin Shan
2022-09-23 14:28     ` Marc Zyngier
2022-09-23 14:28       ` Marc Zyngier
2022-09-23 18:26       ` Peter Xu
2022-09-23 18:26         ` Peter Xu
2022-09-23 21:23         ` Paolo Bonzini
2022-09-23 21:23           ` Paolo Bonzini
2022-09-23 22:34           ` Peter Xu
2022-09-23 22:34             ` Peter Xu
2022-09-24  8:51         ` Marc Zyngier
2022-09-24  8:51           ` Marc Zyngier
2022-09-24 11:26           ` Marc Zyngier
2022-09-24 11:26             ` Marc Zyngier
2022-09-24 13:22             ` Peter Xu
2022-09-24 13:22               ` Peter Xu
2022-09-24 18:57               ` Marc Zyngier [this message]
2022-09-24 18:57                 ` Marc Zyngier
2022-09-25 23:17                 ` Gavin Shan
2022-09-25 23:17                   ` Gavin Shan
2022-09-22 17:01 ` [PATCH 3/6] KVM: x86: Select CONFIG_HAVE_KVM_DIRTY_RING_ORDERED Marc Zyngier
2022-09-22 17:01   ` Marc Zyngier
2022-09-23 22:46   ` Peter Xu
2022-09-23 22:46     ` Peter Xu
2022-09-24  8:47     ` Marc Zyngier
2022-09-24  8:47       ` Marc Zyngier
2022-09-24 13:29       ` Peter Xu
2022-09-24 13:29         ` Peter Xu
2022-09-22 17:01 ` [PATCH 4/6] KVM: Document weakly ordered architecture requirements for dirty ring Marc Zyngier
2022-09-22 17:01   ` Marc Zyngier
2022-09-22 17:01 ` [PATCH 5/6] KVM: selftests: dirty-log: Upgrade dirty_gfn_set_collected() to store-release Marc Zyngier
2022-09-22 17:01   ` Marc Zyngier
2022-09-22 21:38   ` Paolo Bonzini
2022-09-22 21:38     ` Paolo Bonzini
2022-09-23 14:49     ` Marc Zyngier
2022-09-23 14:49       ` Marc Zyngier
2022-09-22 17:01 ` [PATCH 6/6] KVM: selftests: dirty-log: Use KVM_CAP_DIRTY_LOG_RING_ORDERED of available Marc Zyngier
2022-09-22 17:01   ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878rm8ior6.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=andrew.jones@linux.dev \
    --cc=bgardon@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=dmatlack@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=shan.gavin@gmail.com \
    --cc=shuah@kernel.org \
    --cc=will@kernel.org \
    --cc=zhenyzha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.