All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Jessica Clarke <jrtc27@jrtc27.com>
Cc: "open list:RISC-V" <qemu-riscv@nongnu.org>,
	"Anup Patel" <anup.patel@wdc.com>,
	"Alistair Francis" <Alistair.Francis@wdc.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2] goldfish_rtc: Fix non-atomic read behaviour of TIME_LOW/TIME_HIGH
Date: Sat, 18 Jul 2020 19:08:45 +0100	[thread overview]
Message-ID: <CAFEAcA-EHOVEQLGaF_wu3d-LVvC3+bDHo0=xyvzG+769Kus7WQ@mail.gmail.com> (raw)
In-Reply-To: <92816800-F7B8-45CB-9863-96B8DF526D29@jrtc27.com>

On Sat, 18 Jul 2020 at 15:45, Jessica Clarke <jrtc27@jrtc27.com> wrote:
> On 18 Jul 2020, at 08:42, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> > Maybe easier to cache the whole u64, this matches RTC_ALARM_LOW /
> > RTC_ALARM_HIGH pattern (goldfish_rtc_vmstate change not included):
>
> We could, but why waste space storing an extra 32 bits you never need?
> I don't think saving all 64 bits makes it any easier to read, I'd
> personally even argue it makes it slightly less obvious what's going on.

You could go either way. (The original Google-written version
of this device model went for store-the-whole-u64:
https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-2.0-release/hw/android/goldfish/timer.c
but we don't need to follow their implementation.)
Since "save the high half" is the version you've written
and tested, I vote we go with that :-)

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

NB: this is a migration compatibility break for the risc-v
'virt' board : up to Alistair whether that's OK or if the
more awkward compat-maintaining vmstate subsection is worth
the effort.

thanks
-- PMM


WARNING: multiple messages have this Message-ID (diff)
From: Peter Maydell <peter.maydell@linaro.org>
To: Jessica Clarke <jrtc27@jrtc27.com>
Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Alistair Francis" <Alistair.Francis@wdc.com>,
	"Anup Patel" <anup.patel@wdc.com>,
	"open list:RISC-V" <qemu-riscv@nongnu.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2] goldfish_rtc: Fix non-atomic read behaviour of TIME_LOW/TIME_HIGH
Date: Sat, 18 Jul 2020 19:08:45 +0100	[thread overview]
Message-ID: <CAFEAcA-EHOVEQLGaF_wu3d-LVvC3+bDHo0=xyvzG+769Kus7WQ@mail.gmail.com> (raw)
In-Reply-To: <92816800-F7B8-45CB-9863-96B8DF526D29@jrtc27.com>

On Sat, 18 Jul 2020 at 15:45, Jessica Clarke <jrtc27@jrtc27.com> wrote:
> On 18 Jul 2020, at 08:42, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> > Maybe easier to cache the whole u64, this matches RTC_ALARM_LOW /
> > RTC_ALARM_HIGH pattern (goldfish_rtc_vmstate change not included):
>
> We could, but why waste space storing an extra 32 bits you never need?
> I don't think saving all 64 bits makes it any easier to read, I'd
> personally even argue it makes it slightly less obvious what's going on.

You could go either way. (The original Google-written version
of this device model went for store-the-whole-u64:
https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-2.0-release/hw/android/goldfish/timer.c
but we don't need to follow their implementation.)
Since "save the high half" is the version you've written
and tested, I vote we go with that :-)

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

NB: this is a migration compatibility break for the risc-v
'virt' board : up to Alistair whether that's OK or if the
more awkward compat-maintaining vmstate subsection is worth
the effort.

thanks
-- PMM


  reply	other threads:[~2020-07-18 18:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-18  0:20 [PATCH] goldfish_rtc: Fix non-atomic read behaviour of TIME_LOW/TIME_HIGH Jessica Clarke
2020-07-18  0:20 ` Jessica Clarke
2020-07-18  0:43 ` Richard Henderson
2020-07-18  0:43   ` Richard Henderson
2020-07-18  0:49 ` [PATCH v2] " Jessica Clarke
2020-07-18  0:49   ` Jessica Clarke
2020-07-18  7:42   ` Philippe Mathieu-Daudé
2020-07-18  7:42     ` Philippe Mathieu-Daudé
2020-07-18 14:43     ` Jessica Clarke
2020-07-18 14:43       ` Jessica Clarke
2020-07-18 18:08       ` Peter Maydell [this message]
2020-07-18 18:08         ` Peter Maydell
2020-07-20 23:11         ` Alistair Francis
2020-07-20 23:11           ` Alistair Francis
2020-07-18 18:56   ` Richard Henderson
2020-07-18 18:56     ` Richard Henderson

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='CAFEAcA-EHOVEQLGaF_wu3d-LVvC3+bDHo0=xyvzG+769Kus7WQ@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=Alistair.Francis@wdc.com \
    --cc=anup.patel@wdc.com \
    --cc=f4bug@amsat.org \
    --cc=jrtc27@jrtc27.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@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 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.