From: Peter Xu <peterx@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
kvm <kvm@vger.kernel.org>, Marc Zyngier <maz@kernel.org>,
Andrew Jones <andrew.jones@linux.dev>,
Will Deacon <will@kernel.org>, Shan Gavin <shan.gavin@gmail.com>,
Ben Gardon <bgardon@google.com>,
David Matlack <dmatlack@google.com>,
Zhenyu Zhang <zhenyzha@redhat.com>, Shuah Khan <shuah@kernel.org>,
KVM ARM <kvmarm@lists.cs.columbia.edu>
Subject: Re: [PATCH 2/6] KVM: Add KVM_CAP_DIRTY_LOG_RING_ORDERED capability and config option
Date: Fri, 23 Sep 2022 18:34:12 -0400 [thread overview]
Message-ID: <Yy40ZPS4Lp0S6pkf@x1n> (raw)
In-Reply-To: <CABgObfakosSMDYnT+W1zFJCRwPcM7VaY-FJzRs_9NivvhfjnyA@mail.gmail.com>
On Fri, Sep 23, 2022 at 11:23:24PM +0200, Paolo Bonzini wrote:
> Il ven 23 set 2022, 20:26 Peter Xu <peterx@redhat.com> ha scritto:
> >
> > > Someone will show up with an old userspace which probes for the sole
> > > existing capability, and things start failing subtly. It is quite
> > > likely that the userspace code is built for all architectures,
> >
> > I didn't quite follow here. Since both kvm/qemu dirty ring was only
> > supported on x86, I don't see the risk.
>
> Say you run a new ARM kernel on old userspace, and the new kernel uses
> KVM_CAP_DIRTY_LOG_RING. Userspace will try to use the dirty page ring
> buffer even though it lacks the memory barriers that were just
> introduced in QEMU.
>
> The new capability means "the dirty page ring buffer is supported and,
> by the way, you're supposed to do everything right with respect to
> ordering of loads and stores; you can't get away without it like you
> could on x86".
I understand now, thanks both.
--
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: Paolo Bonzini <pbonzini@redhat.com>
Cc: Marc Zyngier <maz@kernel.org>,
KVM ARM <kvmarm@lists.cs.columbia.edu>, kvm <kvm@vger.kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Ben Gardon <bgardon@google.com>, Shuah Khan <shuah@kernel.org>,
Andrew Jones <andrew.jones@linux.dev>,
Will Deacon <will@kernel.org>,
David Matlack <dmatlack@google.com>,
Zhenyu Zhang <zhenyzha@redhat.com>,
Shan Gavin <shan.gavin@gmail.com>, Guowen Shan <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: Fri, 23 Sep 2022 18:34:12 -0400 [thread overview]
Message-ID: <Yy40ZPS4Lp0S6pkf@x1n> (raw)
In-Reply-To: <CABgObfakosSMDYnT+W1zFJCRwPcM7VaY-FJzRs_9NivvhfjnyA@mail.gmail.com>
On Fri, Sep 23, 2022 at 11:23:24PM +0200, Paolo Bonzini wrote:
> Il ven 23 set 2022, 20:26 Peter Xu <peterx@redhat.com> ha scritto:
> >
> > > Someone will show up with an old userspace which probes for the sole
> > > existing capability, and things start failing subtly. It is quite
> > > likely that the userspace code is built for all architectures,
> >
> > I didn't quite follow here. Since both kvm/qemu dirty ring was only
> > supported on x86, I don't see the risk.
>
> Say you run a new ARM kernel on old userspace, and the new kernel uses
> KVM_CAP_DIRTY_LOG_RING. Userspace will try to use the dirty page ring
> buffer even though it lacks the memory barriers that were just
> introduced in QEMU.
>
> The new capability means "the dirty page ring buffer is supported and,
> by the way, you're supposed to do everything right with respect to
> ordering of loads and stores; you can't get away without it like you
> could on x86".
I understand now, thanks both.
--
Peter Xu
next prev parent reply other threads:[~2022-09-23 22:34 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 [this message]
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=Yy40ZPS4Lp0S6pkf@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=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.