All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Cc: will@kernel.org, catalin.marinas@arm.com, andrew.jones@linux.dev,
	shan.gavin@gmail.com, bgardon@google.com, dmatlack@google.com,
	pbonzini@redhat.com, zhenyzha@redhat.com, shuah@kernel.org
Subject: [PATCH 1/6] KVM: Use acquire/release semantics when accessing dirty ring GFN state
Date: Thu, 22 Sep 2022 18:01:28 +0100	[thread overview]
Message-ID: <20220922170133.2617189-2-maz@kernel.org> (raw)
In-Reply-To: <20220922170133.2617189-1-maz@kernel.org>

The current implementation of the dirty ring has an implicit requirement
that stores to the dirty ring from userspace must be:

- be ordered with one another

- visible from another CPU executing a ring reset

While these implicit requirements work well for x86 (and any other
TSO-like architecture), they do not work for more relaxed architectures
such as arm64 where stores to different addresses can be freely
reordered, and loads from these addresses not observing writes from
another CPU unless the required barriers (or acquire/release semantics)
are used.

In order to start fixing this, upgrade the ring reset accesses:

- the kvm_dirty_gfn_harvested() helper now uses acquire semantics
  so it is ordered after all previous writes, including that from
  userspace

- the kvm_dirty_gfn_set_invalid() helper now uses release semantics
  so that the next_slot and next_offset reads don't drift past
  the entry invalidation

This is only a partial fix as the userspace side also need upgrading.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 virt/kvm/dirty_ring.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/dirty_ring.c b/virt/kvm/dirty_ring.c
index f4c2a6eb1666..784bed80221d 100644
--- a/virt/kvm/dirty_ring.c
+++ b/virt/kvm/dirty_ring.c
@@ -79,12 +79,12 @@ static inline void kvm_dirty_gfn_set_invalid(struct kvm_dirty_gfn *gfn)
 
 static inline void kvm_dirty_gfn_set_dirtied(struct kvm_dirty_gfn *gfn)
 {
-	gfn->flags = KVM_DIRTY_GFN_F_DIRTY;
+	smp_store_release(&gfn->flags, KVM_DIRTY_GFN_F_DIRTY);
 }
 
 static inline bool kvm_dirty_gfn_harvested(struct kvm_dirty_gfn *gfn)
 {
-	return gfn->flags & KVM_DIRTY_GFN_F_RESET;
+	return smp_load_acquire(&gfn->flags) & KVM_DIRTY_GFN_F_RESET;
 }
 
 int kvm_dirty_ring_reset(struct kvm *kvm, struct kvm_dirty_ring *ring)
-- 
2.34.1

_______________________________________________
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: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Cc: catalin.marinas@arm.com, bgardon@google.com, shuah@kernel.org,
	andrew.jones@linux.dev, will@kernel.org, dmatlack@google.com,
	peterx@redhat.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: [PATCH 1/6] KVM: Use acquire/release semantics when accessing dirty ring GFN state
Date: Thu, 22 Sep 2022 18:01:28 +0100	[thread overview]
Message-ID: <20220922170133.2617189-2-maz@kernel.org> (raw)
In-Reply-To: <20220922170133.2617189-1-maz@kernel.org>

The current implementation of the dirty ring has an implicit requirement
that stores to the dirty ring from userspace must be:

- be ordered with one another

- visible from another CPU executing a ring reset

While these implicit requirements work well for x86 (and any other
TSO-like architecture), they do not work for more relaxed architectures
such as arm64 where stores to different addresses can be freely
reordered, and loads from these addresses not observing writes from
another CPU unless the required barriers (or acquire/release semantics)
are used.

In order to start fixing this, upgrade the ring reset accesses:

- the kvm_dirty_gfn_harvested() helper now uses acquire semantics
  so it is ordered after all previous writes, including that from
  userspace

- the kvm_dirty_gfn_set_invalid() helper now uses release semantics
  so that the next_slot and next_offset reads don't drift past
  the entry invalidation

This is only a partial fix as the userspace side also need upgrading.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 virt/kvm/dirty_ring.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/dirty_ring.c b/virt/kvm/dirty_ring.c
index f4c2a6eb1666..784bed80221d 100644
--- a/virt/kvm/dirty_ring.c
+++ b/virt/kvm/dirty_ring.c
@@ -79,12 +79,12 @@ static inline void kvm_dirty_gfn_set_invalid(struct kvm_dirty_gfn *gfn)
 
 static inline void kvm_dirty_gfn_set_dirtied(struct kvm_dirty_gfn *gfn)
 {
-	gfn->flags = KVM_DIRTY_GFN_F_DIRTY;
+	smp_store_release(&gfn->flags, KVM_DIRTY_GFN_F_DIRTY);
 }
 
 static inline bool kvm_dirty_gfn_harvested(struct kvm_dirty_gfn *gfn)
 {
-	return gfn->flags & KVM_DIRTY_GFN_F_RESET;
+	return smp_load_acquire(&gfn->flags) & KVM_DIRTY_GFN_F_RESET;
 }
 
 int kvm_dirty_ring_reset(struct kvm *kvm, struct kvm_dirty_ring *ring)
-- 
2.34.1


  reply	other threads:[~2022-09-22 17:01 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 ` Marc Zyngier [this message]
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 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
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=20220922170133.2617189-2-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=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.