Linux KVM/arm64 development list
 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 3/6] KVM: x86: Select CONFIG_HAVE_KVM_DIRTY_RING_ORDERED
Date: Sat, 24 Sep 2022 09:47:59 +0100	[thread overview]
Message-ID: <87fsghi2f4.wl-maz@kernel.org> (raw)
In-Reply-To: <Yy43UM/+qTxc+/qt@x1n>

On Fri, 23 Sep 2022 23:46:40 +0100,
Peter Xu <peterx@redhat.com> wrote:
> 
> 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@kernel.org>
> > ---
> >  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).

The problem is to decide, on a per architecture basis, how to expose
the old property. I'm happy to key it on being x86 specific, but that
feels pretty gross, and totally unnecessary for strongly ordered
architectures (s390?).

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

Memory barriers do not affect the semantics of the userspace, while
the lack thereof do. On strongly ordered architectures,
acquire/release is usually "free", because that's implied by their
memory model. If it thus free for these to implement both versions of
the API.

So are we discussing the cost of couple of (mostly invisible) config
options?

	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

  reply	other threads:[~2022-09-24  8:48 UTC|newest]

Thread overview: 28+ 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 ` [PATCH 1/6] KVM: Use acquire/release semantics when accessing dirty ring GFN state Marc Zyngier
2022-09-22 21:38   ` Peter Xu
2022-09-22 23:46     ` Gavin Shan
2022-09-23 14:40       ` Marc Zyngier
2022-09-23 14:19     ` Marc Zyngier
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 21:48   ` Peter Xu
2022-09-23  0:04     ` Gavin Shan
2022-09-23 14:28     ` Marc Zyngier
2022-09-23 18:26       ` Peter Xu
2022-09-23 21:23         ` Paolo Bonzini
2022-09-23 22:34           ` Peter Xu
2022-09-24  8:51         ` Marc Zyngier
2022-09-24 11:26           ` Marc Zyngier
2022-09-24 13:22             ` Peter Xu
2022-09-24 18:57               ` Marc Zyngier
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-23 22:46   ` Peter Xu
2022-09-24  8:47     ` Marc Zyngier [this message]
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 ` [PATCH 5/6] KVM: selftests: dirty-log: Upgrade dirty_gfn_set_collected() to store-release Marc Zyngier
2022-09-22 21:38   ` Paolo Bonzini
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

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=87fsghi2f4.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox