From: Sean Christopherson <seanjc@google.com>
To: Gavin Shan <gshan@redhat.com>
Cc: maz@kernel.org, kvm@vger.kernel.org, catalin.marinas@arm.com,
andrew.jones@linux.dev, dmatlack@google.com, will@kernel.org,
shan.gavin@gmail.com, bgardon@google.com, kvmarm@lists.linux.dev,
pbonzini@redhat.com, zhenyzha@redhat.com, shuah@kernel.org,
kvmarm@lists.cs.columbia.edu, ajones@ventanamicro.com
Subject: Re: [PATCH v8 3/7] KVM: Support dirty ring in conjunction with bitmap
Date: Mon, 7 Nov 2022 16:05:36 +0000 [thread overview]
Message-ID: <Y2ks0NWEEfN8bWV1@google.com> (raw)
In-Reply-To: <20221104234049.25103-4-gshan@redhat.com>
On Sat, Nov 05, 2022, Gavin Shan wrote:
> diff --git a/virt/kvm/dirty_ring.c b/virt/kvm/dirty_ring.c
> index fecbb7d75ad2..758679724447 100644
> --- a/virt/kvm/dirty_ring.c
> +++ b/virt/kvm/dirty_ring.c
> @@ -21,6 +21,16 @@ u32 kvm_dirty_ring_get_rsvd_entries(void)
> return KVM_DIRTY_RING_RSVD_ENTRIES + kvm_cpu_dirty_log_size();
> }
>
> +bool kvm_use_dirty_bitmap(struct kvm *kvm)
> +{
lockdep_assert_held(&kvm->slots_lock);
To guard against accessing kvm->dirty_ring_with_bitmap without holding slots_lock.
> + return !kvm->dirty_ring_size || kvm->dirty_ring_with_bitmap;
> +}
> +
> @@ -4588,6 +4594,31 @@ static int kvm_vm_ioctl_enable_cap_generic(struct kvm *kvm,
> return -EINVAL;
>
> return kvm_vm_ioctl_enable_dirty_log_ring(kvm, cap->args[0]);
> + case KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP: {
> + struct kvm_memslots *slots;
> + int r = -EINVAL;
> +
> + if (!IS_ENABLED(CONFIG_HAVE_KVM_DIRTY_RING_WITH_BITMAP) ||
> + !kvm->dirty_ring_size)
> + return r;
> +
> + mutex_lock(&kvm->slots_lock);
> +
> + slots = kvm_memslots(kvm);
Sadly, this needs to iterate over all possible memslots thanks to x86's SMM
address space. Might be worth adding a separate helper (that's local to kvm_main.c
to discourage use), e.g.
static bool kvm_are_all_memslots_empty(struct kvm *kvm)
{
int i;
lockdep_assert_held(&kvm->slots_lock);
for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
if (!kvm_memslots_empty(__kvm_memslots(kvm, i)))
return false;
}
return true;
}
> +
> + /*
> + * Avoid a race between memslot creation and enabling the ring +
> + * bitmap capability to guarantee that no memslots have been
> + * created without a bitmap.
Nit, it's not just enabling, the below also allows disabling the bitmap. The
enabling case is definitely the most interesting, but the above wording makes it
sound like the enabling case is the only thing that being given protection. That's
kinda true since KVM frees bitmaps without checking kvm_use_dirty_bitmap(), but
that's not a strict requirement.
And there's no race required, e.g. without this check userspace could simply create
a memslot and then toggle on the capability. Acquiring slots_lock above is what
guards against races.
Might also be worth alluding to the alternative solution of allocating the bitmap
for all memslots here, e.g. something like
/*
* For simplicity, allow toggling ring+bitmap if and only if
* there are no memslots, e.g. to ensure all memslots allocate a
* bitmap after the capability is enabled.
*/
> + */
> + if (kvm_memslots_empty(slots)) {
> + kvm->dirty_ring_with_bitmap = cap->args[0];
> + r = 0;
> + }
> +
> + mutex_unlock(&kvm->slots_lock);
> + return r;
> + }
> default:
> return kvm_vm_ioctl_enable_cap(kvm, cap);
> }
> --
_______________________________________________
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: Sean Christopherson <seanjc@google.com>
To: Gavin Shan <gshan@redhat.com>
Cc: kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu,
kvm@vger.kernel.org, shuah@kernel.org, catalin.marinas@arm.com,
andrew.jones@linux.dev, ajones@ventanamicro.com,
bgardon@google.com, dmatlack@google.com, will@kernel.org,
suzuki.poulose@arm.com, alexandru.elisei@arm.com,
pbonzini@redhat.com, maz@kernel.org, peterx@redhat.com,
oliver.upton@linux.dev, zhenyzha@redhat.com,
shan.gavin@gmail.com
Subject: Re: [PATCH v8 3/7] KVM: Support dirty ring in conjunction with bitmap
Date: Mon, 7 Nov 2022 16:05:36 +0000 [thread overview]
Message-ID: <Y2ks0NWEEfN8bWV1@google.com> (raw)
Message-ID: <20221107160536.qLqB1nnZpQJGyzIqInJZSaT4guF6GNMn_zmxWD5tpss@z> (raw)
In-Reply-To: <20221104234049.25103-4-gshan@redhat.com>
On Sat, Nov 05, 2022, Gavin Shan wrote:
> diff --git a/virt/kvm/dirty_ring.c b/virt/kvm/dirty_ring.c
> index fecbb7d75ad2..758679724447 100644
> --- a/virt/kvm/dirty_ring.c
> +++ b/virt/kvm/dirty_ring.c
> @@ -21,6 +21,16 @@ u32 kvm_dirty_ring_get_rsvd_entries(void)
> return KVM_DIRTY_RING_RSVD_ENTRIES + kvm_cpu_dirty_log_size();
> }
>
> +bool kvm_use_dirty_bitmap(struct kvm *kvm)
> +{
lockdep_assert_held(&kvm->slots_lock);
To guard against accessing kvm->dirty_ring_with_bitmap without holding slots_lock.
> + return !kvm->dirty_ring_size || kvm->dirty_ring_with_bitmap;
> +}
> +
> @@ -4588,6 +4594,31 @@ static int kvm_vm_ioctl_enable_cap_generic(struct kvm *kvm,
> return -EINVAL;
>
> return kvm_vm_ioctl_enable_dirty_log_ring(kvm, cap->args[0]);
> + case KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP: {
> + struct kvm_memslots *slots;
> + int r = -EINVAL;
> +
> + if (!IS_ENABLED(CONFIG_HAVE_KVM_DIRTY_RING_WITH_BITMAP) ||
> + !kvm->dirty_ring_size)
> + return r;
> +
> + mutex_lock(&kvm->slots_lock);
> +
> + slots = kvm_memslots(kvm);
Sadly, this needs to iterate over all possible memslots thanks to x86's SMM
address space. Might be worth adding a separate helper (that's local to kvm_main.c
to discourage use), e.g.
static bool kvm_are_all_memslots_empty(struct kvm *kvm)
{
int i;
lockdep_assert_held(&kvm->slots_lock);
for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
if (!kvm_memslots_empty(__kvm_memslots(kvm, i)))
return false;
}
return true;
}
> +
> + /*
> + * Avoid a race between memslot creation and enabling the ring +
> + * bitmap capability to guarantee that no memslots have been
> + * created without a bitmap.
Nit, it's not just enabling, the below also allows disabling the bitmap. The
enabling case is definitely the most interesting, but the above wording makes it
sound like the enabling case is the only thing that being given protection. That's
kinda true since KVM frees bitmaps without checking kvm_use_dirty_bitmap(), but
that's not a strict requirement.
And there's no race required, e.g. without this check userspace could simply create
a memslot and then toggle on the capability. Acquiring slots_lock above is what
guards against races.
Might also be worth alluding to the alternative solution of allocating the bitmap
for all memslots here, e.g. something like
/*
* For simplicity, allow toggling ring+bitmap if and only if
* there are no memslots, e.g. to ensure all memslots allocate a
* bitmap after the capability is enabled.
*/
> + */
> + if (kvm_memslots_empty(slots)) {
> + kvm->dirty_ring_with_bitmap = cap->args[0];
> + r = 0;
> + }
> +
> + mutex_unlock(&kvm->slots_lock);
> + return r;
> + }
> default:
> return kvm_vm_ioctl_enable_cap(kvm, cap);
> }
> --
next prev parent reply other threads:[~2022-11-07 16:05 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 23:40 [PATCH v8 0/7] KVM: arm64: Enable ring-based dirty memory tracking Gavin Shan
2022-11-04 23:40 ` Gavin Shan
2022-11-04 23:40 ` [PATCH v8 1/7] KVM: x86: Introduce KVM_REQ_DIRTY_RING_SOFT_FULL Gavin Shan
2022-11-04 23:40 ` Gavin Shan
2022-11-04 23:40 ` [PATCH v8 2/7] KVM: Move declaration of kvm_cpu_dirty_log_size() to kvm_dirty_ring.h Gavin Shan
2022-11-04 23:40 ` Gavin Shan
2022-11-04 23:40 ` [PATCH v8 3/7] KVM: Support dirty ring in conjunction with bitmap Gavin Shan
2022-11-04 23:40 ` Gavin Shan
2022-11-06 15:43 ` Marc Zyngier
2022-11-06 15:43 ` Marc Zyngier
2022-11-06 16:22 ` Peter Xu
2022-11-06 16:22 ` Peter Xu
2022-11-06 20:12 ` Marc Zyngier
2022-11-06 20:12 ` Marc Zyngier
2022-11-06 21:06 ` Peter Xu
2022-11-06 21:06 ` Peter Xu
2022-11-06 21:23 ` Gavin Shan
2022-11-06 21:23 ` Gavin Shan
2022-11-07 9:38 ` Marc Zyngier
2022-11-07 9:38 ` Marc Zyngier
2022-11-07 14:29 ` Peter Xu
2022-11-07 14:29 ` Peter Xu
2022-11-07 9:21 ` Marc Zyngier
2022-11-07 9:21 ` Marc Zyngier
2022-11-07 14:59 ` Peter Xu
2022-11-07 14:59 ` Peter Xu
2022-11-07 15:30 ` Marc Zyngier
2022-11-07 15:30 ` Marc Zyngier
2022-11-06 21:40 ` Gavin Shan
2022-11-06 21:40 ` Gavin Shan
2022-11-07 9:45 ` Marc Zyngier
2022-11-07 9:45 ` Marc Zyngier
2022-11-07 10:45 ` Gavin Shan
2022-11-07 10:45 ` Gavin Shan
2022-11-07 11:33 ` Marc Zyngier
2022-11-07 11:33 ` Marc Zyngier
2022-11-07 23:53 ` Gavin Shan
2022-11-07 23:53 ` Gavin Shan
2022-11-07 16:05 ` Sean Christopherson [this message]
2022-11-07 16:05 ` Sean Christopherson
2022-11-08 0:44 ` Gavin Shan
2022-11-08 0:44 ` Gavin Shan
2022-11-08 1:13 ` Oliver Upton
2022-11-08 1:13 ` Oliver Upton
2022-11-08 3:30 ` Gavin Shan
2022-11-08 3:30 ` Gavin Shan
2022-11-04 23:40 ` [PATCH v8 4/7] KVM: arm64: Enable ring-based dirty memory tracking Gavin Shan
2022-11-04 23:40 ` Gavin Shan
2022-11-06 15:50 ` Marc Zyngier
2022-11-06 15:50 ` Marc Zyngier
2022-11-06 21:46 ` Gavin Shan
2022-11-06 21:46 ` Gavin Shan
2022-11-07 9:47 ` Marc Zyngier
2022-11-07 9:47 ` Marc Zyngier
2022-11-07 10:47 ` Gavin Shan
2022-11-07 10:47 ` Gavin Shan
2022-11-04 23:40 ` [PATCH v8 5/7] KVM: selftests: Use host page size to map ring buffer in dirty_log_test Gavin Shan
2022-11-04 23:40 ` Gavin Shan
2022-11-04 23:40 ` [PATCH v8 6/7] KVM: selftests: Clear dirty ring states between two modes " Gavin Shan
2022-11-04 23:40 ` Gavin Shan
2022-11-04 23:40 ` [PATCH v8 7/7] KVM: selftests: Automate choosing dirty ring size " Gavin Shan
2022-11-04 23:40 ` Gavin Shan
2022-11-06 16:08 ` [PATCH v8 0/7] KVM: arm64: Enable ring-based dirty memory tracking Marc Zyngier
2022-11-06 16:08 ` Marc Zyngier
2022-11-06 21:50 ` Gavin Shan
2022-11-06 21:50 ` Gavin Shan
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=Y2ks0NWEEfN8bWV1@google.com \
--to=seanjc@google.com \
--cc=ajones@ventanamicro.com \
--cc=andrew.jones@linux.dev \
--cc=bgardon@google.com \
--cc=catalin.marinas@arm.com \
--cc=dmatlack@google.com \
--cc=gshan@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--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.