From: Catalin Marinas <catalin.marinas@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Steven Price <steven.price@arm.com>,
Peter Maydell <peter.maydell@linaro.org>,
Haibo Xu <haibo.xu@linaro.org>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Juan Quintela <quintela@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
kvmarm <kvmarm@lists.cs.columbia.edu>,
arm-mail-list <linux-arm-kernel@lists.infradead.org>,
Dave Martin <Dave.Martin@arm.com>
Subject: Re: [PATCH v5 0/2] MTE support for KVM guest
Date: Wed, 9 Dec 2020 12:44:43 +0000 [thread overview]
Message-ID: <20201209124443.GB13566@gaia> (raw)
In-Reply-To: <7ff14490e253878d0735633b792e1ea9@kernel.org>
On Tue, Dec 08, 2020 at 06:21:12PM +0000, Marc Zyngier wrote:
> On 2020-12-08 17:21, Catalin Marinas wrote:
> > On Mon, Dec 07, 2020 at 07:03:13PM +0000, Marc Zyngier wrote:
> > > I wonder whether we will have to have something kernel side to
> > > dump/reload tags in a way that matches the patterns used by live
> > > migration.
> >
> > We have something related - ptrace dumps/resores the tags. Can the same
> > concept be expanded to a KVM ioctl?
>
> Yes, although I wonder whether we should integrate this deeply into
> the dirty-log mechanism: it would be really interesting to dump the
> tags at the point where the page is flagged as clean from a dirty-log
> point of view. As the page is dirtied, discard the saved tags.
From the VMM perspective, the tags can be treated just like additional
(meta)data in a page. We'd only need the tags when copying over. It can
race with the VM dirtying the page (writing tags would dirty it) but I
don't think the current migration code cares about this. If dirtied, it
copies it again.
The only downside I see is an extra syscall per page both on the origin
VMM and the destination one to dump/restore the tags. Is this a
performance issue?
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Juan Quintela <quintela@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Dave Martin <Dave.Martin@arm.com>,
Richard Henderson <richard.henderson@linaro.org>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Steven Price <steven.price@arm.com>,
arm-mail-list <linux-arm-kernel@lists.infradead.org>,
Haibo Xu <haibo.xu@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
kvmarm <kvmarm@lists.cs.columbia.edu>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH v5 0/2] MTE support for KVM guest
Date: Wed, 9 Dec 2020 12:44:43 +0000 [thread overview]
Message-ID: <20201209124443.GB13566@gaia> (raw)
In-Reply-To: <7ff14490e253878d0735633b792e1ea9@kernel.org>
On Tue, Dec 08, 2020 at 06:21:12PM +0000, Marc Zyngier wrote:
> On 2020-12-08 17:21, Catalin Marinas wrote:
> > On Mon, Dec 07, 2020 at 07:03:13PM +0000, Marc Zyngier wrote:
> > > I wonder whether we will have to have something kernel side to
> > > dump/reload tags in a way that matches the patterns used by live
> > > migration.
> >
> > We have something related - ptrace dumps/resores the tags. Can the same
> > concept be expanded to a KVM ioctl?
>
> Yes, although I wonder whether we should integrate this deeply into
> the dirty-log mechanism: it would be really interesting to dump the
> tags at the point where the page is flagged as clean from a dirty-log
> point of view. As the page is dirtied, discard the saved tags.
From the VMM perspective, the tags can be treated just like additional
(meta)data in a page. We'd only need the tags when copying over. It can
race with the VM dirtying the page (writing tags would dirty it) but I
don't think the current migration code cares about this. If dirtied, it
copies it again.
The only downside I see is an extra syscall per page both on the origin
VMM and the destination one to dump/restore the tags. Is this a
performance issue?
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Juan Quintela <quintela@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Dave Martin <Dave.Martin@arm.com>,
Richard Henderson <richard.henderson@linaro.org>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Steven Price <steven.price@arm.com>,
arm-mail-list <linux-arm-kernel@lists.infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
kvmarm <kvmarm@lists.cs.columbia.edu>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH v5 0/2] MTE support for KVM guest
Date: Wed, 9 Dec 2020 12:44:43 +0000 [thread overview]
Message-ID: <20201209124443.GB13566@gaia> (raw)
In-Reply-To: <7ff14490e253878d0735633b792e1ea9@kernel.org>
On Tue, Dec 08, 2020 at 06:21:12PM +0000, Marc Zyngier wrote:
> On 2020-12-08 17:21, Catalin Marinas wrote:
> > On Mon, Dec 07, 2020 at 07:03:13PM +0000, Marc Zyngier wrote:
> > > I wonder whether we will have to have something kernel side to
> > > dump/reload tags in a way that matches the patterns used by live
> > > migration.
> >
> > We have something related - ptrace dumps/resores the tags. Can the same
> > concept be expanded to a KVM ioctl?
>
> Yes, although I wonder whether we should integrate this deeply into
> the dirty-log mechanism: it would be really interesting to dump the
> tags at the point where the page is flagged as clean from a dirty-log
> point of view. As the page is dirtied, discard the saved tags.
From the VMM perspective, the tags can be treated just like additional
(meta)data in a page. We'd only need the tags when copying over. It can
race with the VM dirtying the page (writing tags would dirty it) but I
don't think the current migration code cares about this. If dirtied, it
copies it again.
The only downside I see is an extra syscall per page both on the origin
VMM and the destination one to dump/restore the tags. Is this a
performance issue?
--
Catalin
_______________________________________________
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: Catalin Marinas <catalin.marinas@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Juan Quintela <quintela@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Dave Martin <Dave.Martin@arm.com>,
Richard Henderson <richard.henderson@linaro.org>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Steven Price <steven.price@arm.com>,
arm-mail-list <linux-arm-kernel@lists.infradead.org>,
Haibo Xu <haibo.xu@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
kvmarm <kvmarm@lists.cs.columbia.edu>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH v5 0/2] MTE support for KVM guest
Date: Wed, 9 Dec 2020 12:44:43 +0000 [thread overview]
Message-ID: <20201209124443.GB13566@gaia> (raw)
In-Reply-To: <7ff14490e253878d0735633b792e1ea9@kernel.org>
On Tue, Dec 08, 2020 at 06:21:12PM +0000, Marc Zyngier wrote:
> On 2020-12-08 17:21, Catalin Marinas wrote:
> > On Mon, Dec 07, 2020 at 07:03:13PM +0000, Marc Zyngier wrote:
> > > I wonder whether we will have to have something kernel side to
> > > dump/reload tags in a way that matches the patterns used by live
> > > migration.
> >
> > We have something related - ptrace dumps/resores the tags. Can the same
> > concept be expanded to a KVM ioctl?
>
> Yes, although I wonder whether we should integrate this deeply into
> the dirty-log mechanism: it would be really interesting to dump the
> tags at the point where the page is flagged as clean from a dirty-log
> point of view. As the page is dirtied, discard the saved tags.
From the VMM perspective, the tags can be treated just like additional
(meta)data in a page. We'd only need the tags when copying over. It can
race with the VM dirtying the page (writing tags would dirty it) but I
don't think the current migration code cares about this. If dirtied, it
copies it again.
The only downside I see is an extra syscall per page both on the origin
VMM and the destination one to dump/restore the tags. Is this a
performance issue?
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-09 12:45 UTC|newest]
Thread overview: 152+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-19 15:38 [PATCH v5 0/2] MTE support for KVM guest Steven Price
2020-11-19 15:38 ` Steven Price
2020-11-19 15:38 ` Steven Price
2020-11-19 15:38 ` Steven Price
2020-11-19 15:39 ` [PATCH v5 1/2] arm64: kvm: Save/restore MTE registers Steven Price
2020-11-19 15:39 ` Steven Price
2020-11-19 15:39 ` Steven Price
2020-11-19 15:39 ` Steven Price
2020-11-19 15:39 ` [PATCH v5 2/2] arm64: kvm: Introduce MTE VCPU feature Steven Price
2020-11-19 15:39 ` Steven Price
2020-11-19 15:39 ` Steven Price
2020-11-19 15:39 ` Steven Price
2020-11-19 15:45 ` [PATCH v5 0/2] MTE support for KVM guest Peter Maydell
2020-11-19 15:45 ` Peter Maydell
2020-11-19 15:45 ` Peter Maydell
2020-11-19 15:45 ` Peter Maydell
2020-11-19 15:57 ` Steven Price
2020-11-19 15:57 ` Steven Price
2020-11-19 15:57 ` Steven Price
2020-11-19 15:57 ` Steven Price
2020-11-19 16:39 ` Peter Maydell
2020-11-19 16:39 ` Peter Maydell
2020-11-19 16:39 ` Peter Maydell
2020-11-19 16:39 ` Peter Maydell
2020-11-19 18:42 ` Andrew Jones
2020-11-19 18:42 ` Andrew Jones
2020-11-19 18:42 ` Andrew Jones
2020-11-19 18:42 ` Andrew Jones
2020-11-19 19:11 ` Marc Zyngier
2020-11-19 19:11 ` Marc Zyngier
2020-11-19 19:11 ` Marc Zyngier
2020-11-19 19:11 ` Marc Zyngier
2020-11-20 9:50 ` Steven Price
2020-11-20 9:50 ` Steven Price
2020-11-20 9:50 ` Steven Price
2020-11-20 9:50 ` Steven Price
2020-11-20 9:56 ` Marc Zyngier
2020-11-20 9:56 ` Marc Zyngier
2020-11-20 9:56 ` Marc Zyngier
2020-11-20 9:56 ` Marc Zyngier
2020-11-20 9:58 ` Steven Price
2020-11-20 9:58 ` Steven Price
2020-11-20 9:58 ` Steven Price
2020-11-20 9:58 ` Steven Price
2020-12-04 8:25 ` Haibo Xu
2020-12-04 8:25 ` Haibo Xu
2020-12-04 8:25 ` Haibo Xu
2020-12-04 8:25 ` Haibo Xu
2020-12-07 14:48 ` Steven Price
2020-12-07 14:48 ` Steven Price
2020-12-07 14:48 ` Steven Price
2020-12-07 14:48 ` Steven Price
2020-12-07 15:27 ` Peter Maydell
2020-12-07 15:27 ` Peter Maydell
2020-12-07 15:27 ` Peter Maydell
2020-12-07 15:27 ` Peter Maydell
2020-12-07 15:45 ` Steven Price
2020-12-07 15:45 ` Steven Price
2020-12-07 15:45 ` Steven Price
2020-12-07 15:45 ` Steven Price
2020-12-07 16:05 ` Marc Zyngier
2020-12-07 16:05 ` Marc Zyngier
2020-12-07 16:05 ` Marc Zyngier
2020-12-07 16:05 ` Marc Zyngier
2020-12-07 16:34 ` Catalin Marinas
2020-12-07 16:34 ` Catalin Marinas
2020-12-07 16:34 ` Catalin Marinas
2020-12-07 16:34 ` Catalin Marinas
2020-12-07 19:03 ` Marc Zyngier
2020-12-07 19:03 ` Marc Zyngier
2020-12-07 19:03 ` Marc Zyngier
2020-12-07 19:03 ` Marc Zyngier
2020-12-08 17:21 ` Catalin Marinas
2020-12-08 17:21 ` Catalin Marinas
2020-12-08 17:21 ` Catalin Marinas
2020-12-08 17:21 ` Catalin Marinas
2020-12-08 18:21 ` Marc Zyngier
2020-12-08 18:21 ` Marc Zyngier
2020-12-08 18:21 ` Marc Zyngier
2020-12-08 18:21 ` Marc Zyngier
2020-12-09 12:44 ` Catalin Marinas [this message]
2020-12-09 12:44 ` Catalin Marinas
2020-12-09 12:44 ` Catalin Marinas
2020-12-09 12:44 ` Catalin Marinas
2020-12-09 13:25 ` Marc Zyngier
2020-12-09 13:25 ` Marc Zyngier
2020-12-09 13:25 ` Marc Zyngier
2020-12-09 13:25 ` Marc Zyngier
2020-12-09 15:27 ` Catalin Marinas
2020-12-09 15:27 ` Catalin Marinas
2020-12-09 15:27 ` Catalin Marinas
2020-12-09 15:27 ` Catalin Marinas
2020-12-09 18:27 ` Richard Henderson
2020-12-09 18:27 ` Richard Henderson
2020-12-09 18:27 ` Richard Henderson
2020-12-09 18:27 ` Richard Henderson
2020-12-09 18:39 ` Catalin Marinas
2020-12-09 18:39 ` Catalin Marinas
2020-12-09 18:39 ` Catalin Marinas
2020-12-09 18:39 ` Catalin Marinas
2020-12-09 20:13 ` Richard Henderson
2020-12-09 20:13 ` Richard Henderson
2020-12-09 20:13 ` Richard Henderson
2020-12-09 20:13 ` Richard Henderson
2020-12-09 20:20 ` Peter Maydell
2020-12-09 20:20 ` Peter Maydell
2020-12-09 20:20 ` Peter Maydell
2020-12-09 20:20 ` Peter Maydell
2020-12-07 16:44 ` Dr. David Alan Gilbert
2020-12-07 16:44 ` Dr. David Alan Gilbert
2020-12-07 16:44 ` Dr. David Alan Gilbert
2020-12-07 16:44 ` Dr. David Alan Gilbert
2020-12-07 17:10 ` Peter Maydell
2020-12-07 17:10 ` Peter Maydell
2020-12-07 17:10 ` Peter Maydell
2020-12-07 17:10 ` Peter Maydell
2020-12-07 17:44 ` Dr. David Alan Gilbert
2020-12-07 17:44 ` Dr. David Alan Gilbert
2020-12-07 17:44 ` Dr. David Alan Gilbert
2020-12-07 17:44 ` Dr. David Alan Gilbert
2020-12-08 10:05 ` Haibo Xu
2020-12-08 10:05 ` Haibo Xu
2020-12-08 10:05 ` Haibo Xu
2020-12-08 10:05 ` Haibo Xu
2020-12-08 9:51 ` Haibo Xu
2020-12-08 9:51 ` Haibo Xu
2020-12-08 9:51 ` Haibo Xu
2020-12-08 9:51 ` Haibo Xu
2020-12-08 10:01 ` Marc Zyngier
2020-12-08 10:01 ` Marc Zyngier
2020-12-08 10:01 ` Marc Zyngier
2020-12-08 10:01 ` Marc Zyngier
2020-12-08 10:10 ` Haibo Xu
2020-12-08 10:10 ` Haibo Xu
2020-12-08 10:10 ` Haibo Xu
2020-12-08 10:10 ` Haibo Xu
2020-12-16 7:31 ` Haibo Xu
2020-12-16 7:31 ` Haibo Xu
2020-12-16 7:31 ` Haibo Xu
2020-12-16 7:31 ` Haibo Xu
2020-12-16 10:22 ` Steven Price
2020-12-16 10:22 ` Steven Price
2020-12-16 10:22 ` Steven Price
2020-12-16 10:22 ` Steven Price
2020-12-17 1:47 ` Haibo Xu
2020-12-17 1:47 ` Haibo Xu
2020-12-17 1:47 ` Haibo Xu
2020-12-17 1:47 ` Haibo Xu
2020-11-23 12:16 ` Dr. David Alan Gilbert
2020-11-23 12:16 ` Dr. David Alan Gilbert
2020-11-23 12:16 ` Dr. David Alan Gilbert
2020-11-23 12:16 ` Dr. David Alan Gilbert
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=20201209124443.GB13566@gaia \
--to=catalin.marinas@arm.com \
--cc=Dave.Martin@arm.com \
--cc=dgilbert@redhat.com \
--cc=haibo.xu@linaro.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=steven.price@arm.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/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.