From: Juan Quintela <quintela@redhat.com>
To: Haibo Xu <haibo.xu@linaro.org>
Cc: peter.maydell@linaro.org, drjones@redhat.com,
richard.henderson@linaro.org, dgilbert@redhat.com,
qemu-devel@nongnu.org, qemu-arm@nongnu.org, philmd@redhat.com
Subject: Re: [RFC PATCH v2 4/5] Add migration support for KVM guest with MTE
Date: Thu, 25 Mar 2021 16:37:35 +0100 [thread overview]
Message-ID: <87y2ebmegw.fsf@secure.mitica> (raw)
In-Reply-To: <881871e8394fa18a656dfb105d42e6099335c721.1615972140.git.haibo.xu@linaro.org> (Haibo Xu's message of "Wed, 17 Mar 2021 09:28:23 +0000")
Haibo Xu <haibo.xu@linaro.org> wrote:
> To make it easier to keep the page tags sync with
> the page data, tags for one page are appended to
> the data during ram save iteration.
>
> This patch only add the pre-copy migration support.
> Post-copy and compress as well as zero page saving
> are not supported yet.
>
> Signed-off-by: Haibo Xu <haibo.xu@linaro.org>
> #define RAM_SAVE_FLAG_XBZRLE 0x40
> /* 0x80 is reserved in migration.h start with 0x100 next */
> #define RAM_SAVE_FLAG_COMPRESS_PAGE 0x100
> +#define RAM_SAVE_FLAG_MTE 0x200
Flags are really a scarce resource. You are using one here, when you
know that you will always have the feature enable (or not), so you can
do better during negotiation IMHO.
> +void precopy_enable_metadata_migration(void)
> +{
> + if (!ram_state) {
> + return;
> + }
> +
> + ram_state->metadata_enabled = true;
> +}
My understanding is that in your following patch, if mte is enabled, you
will always sent mte tags, for all pages needed, right?
> +static int save_normal_page_mte_tags(QEMUFile *f, uint8_t *addr)
> +{
> + uint8_t *tag_buf = NULL;
> + uint64_t ipa;
> + int size = TARGET_PAGE_SIZE / MTE_GRANULE_SIZE;
> +
> + 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);
size of the buffer is known at start of migration. Just get a buffer
and reuse it?
Do zero pages have mte tags? From migration point of view, a zero page
is a page that is just full of zeros, i.e. nothing else special.
Because you are not sending any for them.
> @@ -1148,6 +1219,10 @@ static bool control_save_page(RAMState *rs, RAMBlock *block, ram_addr_t offset,
> static int save_normal_page(RAMState *rs, RAMBlock *block, ram_addr_t offset,
> uint8_t *buf, bool async)
> {
> + if (rs->metadata_enabled) {
> + offset |= RAM_SAVE_FLAG_MTE;
You don't really need the flag, for you normal pages are just
TARGET_PAGE_SIZE + (TARGET_PAGE_SIZE/MTE_)
> + }
> +
> ram_counters.transferred += save_page_header(rs, rs->f, block,
> offset | RAM_SAVE_FLAG_PAGE);
> if (async) {
> @@ -1159,6 +1234,11 @@ static int save_normal_page(RAMState *rs, RAMBlock *block, ram_addr_t offset,
> }
> ram_counters.transferred += TARGET_PAGE_SIZE;
> ram_counters.normal++;
> +
> + if (rs->metadata_enabled) {
See? You are not checking the flag, you are checking the bool setup at
the beggining of migration.
> + ram_counters.transferred += save_normal_page_mte_tags(rs->f, buf);
> + }
> +
> return 1;
> }
>
> @@ -2189,6 +2269,7 @@ static void ram_state_reset(RAMState *rs)
> rs->last_version = ram_list.version;
> rs->ram_bulk_stage = true;
> rs->fpo_enabled = false;
> + rs->metadata_enabled = false;
> }
>
> #define MAX_WAIT 50 /* ms, half buffered_file limit */
> @@ -3779,7 +3860,7 @@ static int ram_load_precopy(QEMUFile *f)
> trace_ram_load_loop(block->idstr, (uint64_t)addr, flags, host);
> }
>
> - switch (flags & ~RAM_SAVE_FLAG_CONTINUE) {
> + switch (flags & ~(RAM_SAVE_FLAG_CONTINUE | RAM_SAVE_FLAG_MTE)) {
Creating the flag is hurting you here also.
> case RAM_SAVE_FLAG_MEM_SIZE:
> /* Synchronize RAM block list */
> total_ram_bytes = addr;
> @@ -3849,6 +3930,9 @@ static int ram_load_precopy(QEMUFile *f)
>
> case RAM_SAVE_FLAG_PAGE:
> qemu_get_buffer(f, host, TARGET_PAGE_SIZE);
> + if (flags & RAM_SAVE_FLAG_MTE) {
> + load_normal_page_mte_tags(f, host);
> + }
I don't claim to understand the MTE, but my understanding is that if we
are using MTE, all pages have to have MTE flags, right?
So, somtehing like
is_mte_enabled()
that I told in the other thread looks like a good idea.
Later, Juan.
> break;
>
> case RAM_SAVE_FLAG_COMPRESS_PAGE:
next prev parent reply other threads:[~2021-03-25 15:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 9:28 [RFC PATCH v2 0/5] target/arm: Add MTE support to KVM guest Haibo Xu
2021-03-17 9:28 ` [RFC PATCH v2 1/5] Update Linux headers with new MTE support Haibo Xu
2021-03-17 9:28 ` [RFC PATCH v2 2/5] Add basic MTE support to KVM guest Haibo Xu
2021-03-17 9:28 ` [RFC PATCH v2 3/5] Add APIs to get/set MTE tags Haibo Xu
2021-03-25 12:18 ` Juan Quintela
2021-04-01 13:12 ` Haibo Xu
2021-03-17 9:28 ` [RFC PATCH v2 4/5] Add migration support for KVM guest with MTE Haibo Xu
2021-03-17 20:11 ` Dr. David Alan Gilbert
2021-03-18 6:38 ` Haibo Xu
2021-03-25 19:37 ` Dr. David Alan Gilbert
2021-04-01 13:33 ` Haibo Xu
2021-03-25 15:37 ` Juan Quintela [this message]
2021-04-01 13:26 ` Haibo Xu
2021-03-17 9:28 ` [RFC PATCH v2 5/5] Enable the MTE support for KVM guest Haibo Xu
2021-03-25 12:40 ` Juan Quintela
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=87y2ebmegw.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=dgilbert@redhat.com \
--cc=drjones@redhat.com \
--cc=haibo.xu@linaro.org \
--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).