qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Haibo Xu <haibo.xu@linaro.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Andrew Jones" <drjones@redhat.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [RFC PATCH 4/5] Add migration support for KVM guest with MTE
Date: Mon, 22 Feb 2021 17:46:06 +0800	[thread overview]
Message-ID: <CAJc+Z1EERnkp1QhZu0Xkrxuw3u8bFM02x0=QVfXYxCRSbXiZeA@mail.gmail.com> (raw)
In-Reply-To: <ae0326e2-8766-803a-ef89-1155d45fdd2a@linaro.org>

On Tue, 16 Feb 2021 at 23:31, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 2/7/21 7:20 PM, Haibo Xu wrote:
> > +    if (kvm_physical_memory_addr_from_host(kvm_state, addr, &ipa)) {
> > +        /* Buffer for the page tags(one byte per tag) */
> > +        tag_buf = g_try_malloc0(size);
> > +        if (!tag_buf) {
> > +            error_report("%s: Error allocating MTE tag_buf", __func__);
> > +            return 0;
> > +        }
> > +
> > +        if (kvm_arm_mte_get_tags(ipa, TARGET_PAGE_SIZE, tag_buf) < 0) {
> > +            error_report("%s: Can't get MTE tags from guest", __func__);
> > +            g_free(tag_buf);
> > +            return 0;
> > +        }
> > +
> > +        qemu_put_buffer(f, tag_buf, size);
> > +
> > +        g_free(tag_buf);
> > +
> > +        return size;
> > +    }
>
> So, in patch 2 you disabled the allocation of tag-memory.  Now you're
> allocating new memory (admittedly quite a small amount -- 1/16th of a page,
> small enough to just be a local variable).
>

Hi Richard!

Thanks so much for the comments!

Yes, the allocated memory here is for temporary tag storage. As you
mentioned, it can be
defined as a local variable which is reserved for temporary tag buffers.

> Why don't you allocate tag-memory, copy the data into it, and then let
> migration proceed as normal.  Then you don't have to have a random data block
> that happens to follow each ram page.
>

As I mentioned in the cover later, the reason to let the tag go with
the memory data together
is to make it easier to sync with each other. I think if we migratie
them separately, it would be
hard to keep the tags to sync with the data.

Saying if we migration all the data first, then the tags. If the data
got dirty during the migration
of the tag memory, we may need to send the data again, or freeze the
source VM after data
migration? What's more, the KVM_GET_DIRTY_LOG API may not be able to
differentiate
between a tag and data changes.

I'm not sure whether the aforementioned situation does exist. Please
correct me if something goes wrong!

> I'm concerned that what you're doing here makes it impossible to migrate
> between kvm and tcg.
>
>

You mean to migrate from a KVM mode VM to a TCG mode VM?

> r~

Regards,
Haibo


  reply	other threads:[~2021-02-22  9:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08  3:20 [RFC PATCH 0/5] target/arm: Add MTE support to KVM guest Haibo Xu
2021-02-08  3:20 ` [RFC PATCH 1/5] Update Linux headers with new MTE support Haibo Xu
2021-03-12  1:48   ` Haibo Xu
2021-02-08  3:20 ` [RFC PATCH 2/5] Add basic MTE support to KVM guest Haibo Xu
2021-03-12  1:49   ` Haibo Xu
2021-02-08  3:20 ` [RFC PATCH 3/5] Add APIs to get/set MTE tags Haibo Xu
2021-03-12  1:50   ` Haibo Xu
2021-02-08  3:20 ` [RFC PATCH 4/5] Add migration support for KVM guest with MTE Haibo Xu
2021-02-16 15:31   ` Richard Henderson
2021-02-22  9:46     ` Haibo Xu [this message]
2021-02-22 22:47       ` Richard Henderson
2021-03-12  1:50         ` Haibo Xu
2021-02-08  3:20 ` [RFC PATCH 5/5] Enable the MTE support for KVM guest Haibo Xu
2021-03-12  1:51   ` Haibo Xu
2021-02-16 11:20 ` [RFC PATCH 0/5] target/arm: Add MTE support to " Peter Maydell
2021-02-22  4:18   ` Haibo Xu

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='CAJc+Z1EERnkp1QhZu0Xkrxuw3u8bFM02x0=QVfXYxCRSbXiZeA@mail.gmail.com' \
    --to=haibo.xu@linaro.org \
    --cc=drjones@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).