From: Peter Maydell <peter.maydell@linaro.org>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
"aleksandar.rikalo@syrmia.com" <aleksandar.rikalo@syrmia.com>,
"aurelien@aurel32.net" <aurelien@aurel32.net>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [PATCH] target/mips: Fix PageMask with variable page size
Date: Mon, 15 Jun 2020 10:23:27 +0100 [thread overview]
Message-ID: <CAFEAcA8f3TsKz7qK00c-ert+cNGEo6gsN_MYmSSmFBWkbJnWDQ@mail.gmail.com> (raw)
In-Reply-To: <9a3f44fc-d279-c003-a8f6-0771e86cc3d0@flygoat.com>
On Mon, 15 Jun 2020 at 10:17, Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
>
>
> 在 2020/6/15 17:13, Peter Maydell 写道:
> > On Sun, 14 Jun 2020 at 22:52, Aleksandar Markovic
> > <aleksandar.qemu.devel@gmail.com> wrote:
> >> When you change machine.c the way you did it, you need to bump the version. Please see git log on machine.c for details.
> >
> >>> --- a/target/mips/cpu.h
> >>> +++ b/target/mips/cpu.h
> >>> @@ -617,7 +617,8 @@ struct CPUMIPSState {
> >>> /*
> >>> * CP0 Register 5
> >>> */
> >>> - int32_t CP0_PageMask;
> >>> + target_ulong CP0_PageMask;
> >>> +#define CP0PM_MASK 13
> >
> > Does CP0_PageMask ever actually hold a value that won't fit
> > in an int32_t? If not, it might be preferable to avoid changing
> > its type to avoid the migration compat break, even if MIPS
> > doesn't have any versioned boards where we have a strict
> > don't-break-compat promise to users.
>
> In Release2, PageMask was extended to 64bit on MIPS64 processors.
>
> Is it necessary to follow that?
Ah, I see. I'd assumed that you were only fixing the
variable-page-size change (which shouldn't require a
change in the type), but as Aleksandar says you've
mixed in a new feature implementation in the same commit
(which from what you're saying does need the type to change).
If the new feature means the register is now 64 bits then
it is possible to implement this in a migration-compatible
way by using a vmstate subsection; I'll leave it up to
Aleksandar whether that complexity is something that makes
sense for MIPS targets or if it's better to just break migration
compat by bumping the version.
thanks
-- PMM
next prev parent reply other threads:[~2020-06-15 9:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-14 3:47 [PATCH] target/mips: Fix PageMask with variable page size Jiaxun Yang
2020-06-14 4:13 ` no-reply
2020-06-14 21:51 ` Aleksandar Markovic
2020-06-15 9:13 ` Peter Maydell
2020-06-15 9:16 ` Jiaxun Yang
2020-06-15 9:23 ` Peter Maydell [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-06-09 2:47 Jiaxun Yang
2020-06-09 4:05 ` Jiaxun Yang
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=CAFEAcA8f3TsKz7qK00c-ert+cNGEo6gsN_MYmSSmFBWkbJnWDQ@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=aleksandar.qemu.devel@gmail.com \
--cc=aleksandar.rikalo@syrmia.com \
--cc=aurelien@aurel32.net \
--cc=jiaxun.yang@flygoat.com \
--cc=qemu-devel@nongnu.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).