From: Peter Xu <peterx@redhat.com>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: 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
Subject: Re: [PATCH v5 3/7] KVM: x86: Allow to use bitmap in ring-based dirty page tracking
Date: Tue, 18 Oct 2022 11:50:59 -0400 [thread overview]
Message-ID: <Y07LY41y6ZRL3d3S@x1n> (raw)
In-Reply-To: <Y05X4o1TxxkvES9E@google.com>
On Tue, Oct 18, 2022 at 10:38:10AM +0300, Oliver Upton wrote:
> If we ever get to the point that we can relax this restriction i think a
> flag on the BITMAP_WITH_TABLE cap that says "I don't actually set any
> bits in the bitmap" would do. We shouldn't hide the cap entirely, as
> that would be ABI breakage for VMMs that expect bitmap+ring.
I'd rather drop the cap directly if it's just a boolean that tells us
"whether we need bitmap to back rings". Btw when I said "dropping it" I
meant "don't return 1 for the cap anymore" - we definitely need to make the
cap macro stable as part of kvm API..
But I think I misunderstood the proposal previously, sorry. I assumed we
were discussing an internal HAVE_DIRTY_RING_WITH_BITMAP only. I noticed
this only after I had a closer look at Gavin's patch. Having a cap exposed
sounds always good to me.
I'll comment on Gavin's patch directly, thanks.
--
Peter Xu
_______________________________________________
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: Peter Xu <peterx@redhat.com>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Gavin Shan <gshan@redhat.com>,
kvmarm@lists.linux.dev, 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,
james.morse@arm.com, suzuki.poulose@arm.com,
alexandru.elisei@arm.com, seanjc@google.com,
shan.gavin@gmail.com
Subject: Re: [PATCH v5 3/7] KVM: x86: Allow to use bitmap in ring-based dirty page tracking
Date: Tue, 18 Oct 2022 11:50:59 -0400 [thread overview]
Message-ID: <Y07LY41y6ZRL3d3S@x1n> (raw)
Message-ID: <20221018155059.TGyqo18Fk_pkEIEZZ_016yPLKxFs-owZRPA27cRqYkA@z> (raw)
In-Reply-To: <Y05X4o1TxxkvES9E@google.com>
On Tue, Oct 18, 2022 at 10:38:10AM +0300, Oliver Upton wrote:
> If we ever get to the point that we can relax this restriction i think a
> flag on the BITMAP_WITH_TABLE cap that says "I don't actually set any
> bits in the bitmap" would do. We shouldn't hide the cap entirely, as
> that would be ABI breakage for VMMs that expect bitmap+ring.
I'd rather drop the cap directly if it's just a boolean that tells us
"whether we need bitmap to back rings". Btw when I said "dropping it" I
meant "don't return 1 for the cap anymore" - we definitely need to make the
cap macro stable as part of kvm API..
But I think I misunderstood the proposal previously, sorry. I assumed we
were discussing an internal HAVE_DIRTY_RING_WITH_BITMAP only. I noticed
this only after I had a closer look at Gavin's patch. Having a cap exposed
sounds always good to me.
I'll comment on Gavin's patch directly, thanks.
--
Peter Xu
next prev parent reply other threads:[~2022-10-18 15:51 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-05 0:41 [PATCH v5 0/7] KVM: arm64: Enable ring-based dirty memory tracking Gavin Shan
2022-10-05 0:41 ` Gavin Shan
2022-10-05 0:41 ` [PATCH v5 1/7] KVM: x86: Introduce KVM_REQ_RING_SOFT_FULL Gavin Shan
2022-10-05 0:41 ` Gavin Shan
2022-10-05 0:41 ` [PATCH v5 2/7] KVM: x86: Move declaration of kvm_cpu_dirty_log_size() to kvm_dirty_ring.h Gavin Shan
2022-10-05 0:41 ` Gavin Shan
2022-10-05 0:41 ` [PATCH v5 3/7] KVM: x86: Allow to use bitmap in ring-based dirty page tracking Gavin Shan
2022-10-05 0:41 ` Gavin Shan
2022-10-06 20:28 ` Peter Xu
2022-10-06 20:28 ` Peter Xu
2022-10-06 23:38 ` Gavin Shan
2022-10-06 23:38 ` Gavin Shan
2022-10-07 14:31 ` Peter Xu
2022-10-07 14:31 ` Peter Xu
2022-10-10 23:18 ` Oliver Upton
2022-10-10 23:18 ` Oliver Upton
2022-10-10 23:43 ` Oliver Upton
2022-10-10 23:43 ` Oliver Upton
2022-10-10 23:49 ` Peter Xu
2022-10-10 23:49 ` Peter Xu
2022-10-10 23:58 ` Gavin Shan
2022-10-10 23:58 ` Gavin Shan
2022-10-10 23:58 ` Oliver Upton
2022-10-10 23:58 ` Oliver Upton
2022-10-11 0:20 ` Peter Xu
2022-10-11 0:20 ` Peter Xu
2022-10-11 1:12 ` Oliver Upton
2022-10-11 1:12 ` Oliver Upton
2022-10-11 3:56 ` Gavin Shan
2022-10-11 3:56 ` Gavin Shan
2022-10-11 6:31 ` Gavin Shan
2022-10-11 6:31 ` Gavin Shan
2022-10-14 16:55 ` Peter Xu
2022-10-14 16:55 ` Peter Xu
2022-10-18 7:38 ` Oliver Upton
2022-10-18 7:38 ` Oliver Upton
2022-10-18 7:40 ` Oliver Upton
2022-10-18 7:40 ` Oliver Upton
2022-10-18 15:50 ` Peter Xu [this message]
2022-10-18 15:50 ` Peter Xu
2022-10-05 0:41 ` [PATCH v5 4/7] KVM: arm64: Enable ring-based dirty memory tracking Gavin Shan
2022-10-05 0:41 ` Gavin Shan
2022-10-05 0:41 ` [PATCH v5 5/7] KVM: selftests: Use host page size to map ring buffer in dirty_log_test Gavin Shan
2022-10-05 0:41 ` Gavin Shan
2022-10-05 0:41 ` [PATCH v5 6/7] KVM: selftests: Clear dirty ring states between two modes " Gavin Shan
2022-10-05 0:41 ` Gavin Shan
2022-10-05 0:41 ` [PATCH v5 7/7] KVM: selftests: Automate choosing dirty ring size " Gavin Shan
2022-10-05 0:41 ` 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=Y07LY41y6ZRL3d3S@x1n \
--to=peterx@redhat.com \
--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=kvmarm@lists.linux.dev \
--cc=oliver.upton@linux.dev \
--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.