From: Edgar Iglesias <edgari@xilinx.com>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: "thuth@redhat.com" <thuth@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"f4bug@amsat.org" <f4bug@amsat.org>
Subject: Re: [PATCH v2 05/12] target/microblaze: Fill in VMStateDescription for cpu
Date: Fri, 4 Sep 2020 15:31:01 +0000 [thread overview]
Message-ID: <4876c9af-65c7-4df8-a5a8-44c5b8ca7253@xilinx.com> (raw)
In-Reply-To: <07370a54-846f-9dd9-e6f2-1c9bdf216e3c@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
On 4 Sep 2020 17:25, Richard Henderson <richard.henderson@linaro.org> wrote:
>
> On 9/4/20 5:20 AM, Edgar E. Iglesias wrote:
> >> +static VMStateField vmstate_mmu_fields[] = {
> >> + VMSTATE_UINT64_2DARRAY(rams, MicroBlazeMMU, 2, TLB_ENTRIES),
> >> + VMSTATE_UINT8_ARRAY(tids, MicroBlazeMMU, TLB_ENTRIES),
> >> + VMSTATE_UINT32_ARRAY(regs, MicroBlazeMMU, 3),
> >> + VMSTATE_INT32(c_mmu, MicroBlazeMMU),
> >> + VMSTATE_INT32(c_mmu_tlb_access, MicroBlazeMMU),
> >> + VMSTATE_INT32(c_mmu_zones, MicroBlazeMMU),
> >> + VMSTATE_UINT64(c_addr_mask, MicroBlazeMMU),
> >
> > These last 4 entries are elaboration-time settings, i.e they will not
> > change during VM runtime. I don't think we need to transfer these since
> > we expect the peer to setup the same kind of microblaze?
>
> Ah, I see. Yes, migration is only supported between "like" systems.
>
> Though in this case I wasn't thinking so much of migration and the other uses
> to which VMState gets put, like record/replay and the follow-on patches for gdb
> reverse debugging.
>
> >> + VMSTATE_UINT32_ARRAY(pvr.regs, CPUMBState, 13),
> >
> > pvr.regs are also elaboration time setup and should be read-only during
> > the VM's lifetime.
>
> What do you think about moving all of these to cpu->cfg, so that all of the
> configuration-time stuff is together?
That would be great, thanks!
Btw, I was running tests on this series and saw some regressions but I've got other stuff moving in my tree so it may very well not be related but I'd like to make sure. Will probably take me a few days to figure things out...
Best regards,
Edgar
>
>
> r~
>
>
> >
> > If you fix those, this looks good to me.:
> > Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
> >
>
[-- Attachment #2: Type: text/html, Size: 3242 bytes --]
next prev parent reply other threads:[~2020-09-04 15:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-03 7:26 [PATCH v2 00/12] target/microblaze improvements Richard Henderson
2020-09-03 7:26 ` [PATCH v2 01/12] target/microblaze: Collected fixes for env->iflags Richard Henderson
2020-09-03 7:26 ` [PATCH v2 02/12] target/microblaze: Renumber D_FLAG Richard Henderson
2020-09-03 7:26 ` [PATCH v2 03/12] target/microblaze: Cleanup mb_cpu_do_interrupt Richard Henderson
2020-09-03 7:26 ` [PATCH v2 04/12] target/microblaze: Rename mmu structs Richard Henderson
2020-09-04 12:10 ` Edgar E. Iglesias
2020-09-04 12:43 ` Philippe Mathieu-Daudé
2020-09-03 7:26 ` [PATCH v2 05/12] target/microblaze: Fill in VMStateDescription for cpu Richard Henderson
2020-09-04 12:20 ` Edgar E. Iglesias
2020-09-04 15:25 ` Richard Henderson
2020-09-04 15:31 ` Edgar Iglesias [this message]
2020-09-03 7:26 ` [PATCH v2 06/12] target/microblaze: Rename DISAS_UPDATE to DISAS_EXIT Richard Henderson
2020-09-04 12:44 ` Philippe Mathieu-Daudé
2020-09-03 7:26 ` [PATCH v2 07/12] target/microblaze: Introduce DISAS_EXIT_NEXT, DISAS_EXIT_JUMP Richard Henderson
2020-09-03 7:26 ` [PATCH v2 08/12] target/microblaze: Replace cpustate_changed with DISAS_EXIT_NEXT Richard Henderson
2020-09-03 7:26 ` [PATCH v2 09/12] target/microblaze: Handle DISAS_EXIT_NEXT in delay slot Richard Henderson
2020-09-03 7:26 ` [PATCH v2 10/12] target/microblaze: Force rtid, rted, rtbd to exit Richard Henderson
2020-09-03 7:26 ` [PATCH v2 11/12] target/microblaze: Use tcg_gen_lookup_and_goto_ptr Richard Henderson
2020-09-03 7:26 ` [PATCH v2 12/12] target/microblaze: Diagnose invalid insns in delay slots Richard Henderson
2020-09-04 12:27 ` Edgar E. Iglesias
2020-09-03 12:24 ` [PATCH v2 00/12] target/microblaze improvements Thomas Huth
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=4876c9af-65c7-4df8-a5a8-44c5b8ca7253@xilinx.com \
--to=edgari@xilinx.com \
--cc=f4bug@amsat.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@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 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).