From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Richard Henderson <rth@twiddle.net>
Cc: Yongbok Kim <yongbok.kim@imgtec.com>,
peter.maydell@linaro.org, Leon Alrae <leon.alrae@imgtec.com>,
qemu-devel@nongnu.org, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH v3 2/2] target-mips: Misaligned memory accesses for MSA
Date: Wed, 13 May 2015 23:54:47 +0100 (BST) [thread overview]
Message-ID: <alpine.LFD.2.11.1505132255250.1538@eddie.linux-mips.org> (raw)
In-Reply-To: <5553C3C2.9070101@twiddle.net>
On Wed, 13 May 2015, Richard Henderson wrote:
> >> I believe the problem is that MSA vector register's size is 16-bytes
> >> (this DATA_SIZE isn't supported in softmmu_template) and MSA load/store
> >> is supposed to be atomic.
> >
> > Not really AFAICT. Here's what the specification says[1]:
> >
> > "The vector load instruction is atomic at the element level with no
> > guaranteed ordering among elements, i.e. each element load is an atomic
> > operation issued in no particular order with respect to the element's
> > vector position."
> >
> > and[2]:
> >
> > "The vector store instruction is atomic at the element level with no
> > guaranteed ordering among elements, i.e. each element store is an atomic
> > operation issued in no particular order with respect to the element's
> > vector position."
> >
> > so you only need to get atomic up to 8 bytes (with LD.D and ST.D, less
> > with the narrower vector elements), and that looks supported to me.
>
> There's "atomic" in the transactional sense, and then there's "atomic" in the
> visibility to other actors on the bus sense.
>
> Presumably Leon is talking about the first, wherein we must ensure all writes
> to both pages must succeed. Which just means making sure that both pages are
> present and writable before modifying any memory.
I don't think we have. The specification is a bit unclear I must admit
and it also defines the details of vector load and store operations as
implementation dependent, so there's no further clarification.
However any unaligned loads or stores that cross a data-bus-width
boundary require two bus cycles to complete and therefore by definition
are not atomic in the visibility to other actors on the bus sense.
Therefore the only atomicity sense that can be considered here is I
believe transactional, on the per-element basis as this is what the
specification refers to.
Then the exact semantics of loads and stores is left up to the
implementer, so for example ST.H can be implemented as 2
doubleword-store transactions, or 4 word-store transactions (that
wouldn't be allowed with ST.D), or 8 halfword-store transactions (that
wouldn't be allowed with ST.W), but not 16 byte-store transactions (that
would be allowed with ST.B).
Consequently I believe only individual vector element writes (or reads,
for that matter) are required to either successfully complete or
completely back out, and a TLB, an address error or a bus error
exception (or perhaps a hardware interrupt exception even) happening in
the middle of a vector load or store instruction may observe the
destination vector register or memory respectively partially updated
with elements already transferred (but not an individual element
partially transferred).
That would be consistent with what happens with the other multi-word
transfer instructions I mentioned when they get interrupted on the way
(yes, they do allow hardware interrupts to break them too) and likely
easier to implement as well.
That's just my intepretation though. Perhaps the specification needs a
further clarification.
Maciej
next prev parent reply other threads:[~2015-05-13 22:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-13 15:37 [Qemu-devel] [PATCH v3 0/2] target-mips: Add support for misaligned accesses Yongbok Kim
2015-05-13 15:37 ` [Qemu-devel] [PATCH v3 1/2] target-mips: Misaligned memory accesses for R6 Yongbok Kim
2015-05-13 15:37 ` [Qemu-devel] [PATCH v3 2/2] target-mips: Misaligned memory accesses for MSA Yongbok Kim
2015-05-13 19:28 ` Richard Henderson
2015-05-13 19:56 ` Maciej W. Rozycki
2015-05-13 19:58 ` Richard Henderson
2015-05-13 20:59 ` Leon Alrae
2015-05-13 21:21 ` Maciej W. Rozycki
2015-05-13 21:36 ` Richard Henderson
2015-05-13 22:54 ` Maciej W. Rozycki [this message]
2015-05-14 8:51 ` Leon Alrae
2015-05-14 11:22 ` Maciej W. Rozycki
2015-05-13 21:31 ` Richard Henderson
2015-05-14 9:00 ` Yongbok Kim
2015-05-14 9:46 ` Yongbok Kim
2015-05-14 18:44 ` Richard Henderson
2015-05-14 9:50 ` Leon Alrae
2015-05-14 15:27 ` Richard Henderson
2015-05-14 19:12 ` Richard Henderson
2015-05-15 12:09 ` Leon Alrae
2015-05-15 13:43 ` Richard Henderson
2015-05-15 14:04 ` Leon Alrae
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=alpine.LFD.2.11.1505132255250.1538@eddie.linux-mips.org \
--to=macro@linux-mips.org \
--cc=afaerber@suse.de \
--cc=leon.alrae@imgtec.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=yongbok.kim@imgtec.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 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.