All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Nicholas Piggin" <npiggin@gmail.com>,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>
Cc: "Richard Henderson" <richard.henderson@linaro.org>,
	<qemu-ppc@nongnu.org>, <qemu-devel@nongnu.org>,
	<qemu-stable@nongnu.org>
Subject: Re: [PATCH 2/4] target/ppc: Ensure stcx size matches larx
Date: Mon, 05 Jun 2023 16:27:37 +1000	[thread overview]
Message-ID: <CT4I52C30RXG.AESIFCY16U6T@wheely> (raw)
In-Reply-To: <20230604102858.148584-2-npiggin@gmail.com>

On Sun Jun 4, 2023 at 8:28 PM AEST, Nicholas Piggin wrote:
> Differently-sized larx/stcx. pairs can succeed if the starting address
> matches. Add a size check to require stcx. exactly match the larx that
> established the reservation.

Hmm, question: reserve_addr is a VMSTATE field, but reserve_val is not
(nor reserve_size after this patch).

Blue Swirl added that with commit a456d59c20f ("VM load/save support for
PPC CPU"), and when reserve_val was added in commit 18b21a2f83a
("target-ppc: retain l{w,d}arx loaded value") it did not get migrated.

Could we end up with reserve_addr != -1, but with a bogus reserve_val,
which could then permit a stcx. incorrectly? Not entirely outlandish if
reserve_val starts out initialised to zero.

Could we just clear the reserve in cpu_post_load? It is permitted to be
lost for an implementation-specific reason. Doesn't seem necessary to
try keep it alive over a migration.

Thanks,
Nick


  parent reply	other threads:[~2023-06-05  6:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-04 10:28 [PATCH 1/4] target/ppc: Fix lqarx to set cpu_reserve Nicholas Piggin
2023-06-04 10:28 ` [PATCH 2/4] target/ppc: Ensure stcx size matches larx Nicholas Piggin
2023-06-04 16:58   ` Richard Henderson
2023-06-05  6:27   ` Nicholas Piggin [this message]
2023-06-19 15:48     ` Richard Henderson
2023-06-19 15:55       ` Peter Maydell
2023-06-19 17:02         ` Richard Henderson
2023-06-19 17:14           ` Peter Maydell
2023-06-20  3:39             ` Nicholas Piggin
2023-06-04 10:28 ` [PATCH 3/4] target/ppc: Remove larx/stcx. memory barrier semantics Nicholas Piggin
2023-06-04 16:12   ` Richard Henderson
2023-06-04 10:28 ` [PATCH 4/4] target/ppc: Rework store conditional to avoid branch Nicholas Piggin
2023-06-04 16:22   ` Richard Henderson
2023-06-04 16:05 ` [PATCH 1/4] target/ppc: Fix lqarx to set cpu_reserve Richard Henderson
2023-06-05  2:33   ` Nicholas Piggin

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=CT4I52C30RXG.AESIFCY16U6T@wheely \
    --to=npiggin@gmail.com \
    --cc=danielhb413@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-stable@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 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.