[Qemu-devel] MTTCG and atomicity of loads and stores from QEMU C helper functions

[Qemu-devel] MTTCG and atomicity of loads and stores from QEMU C helper functions

[Peter Maydell]

We have a fair amount of code in QEMU which is helper functions
written in C which make guest memory accesses -- the most common
case being page table walk code.

Generally in CPU architectures the accesses by things like the
page table walker have some atomicity guarantees. For instance
Arm requires that reads of translation tables are single-copy-atomic
(v8A Arm ARM rev B.a section B2.2.1). If we supported the
hardware management of the Access flag (we don't currently) that
wolud have to be an atomic read-modify-write of the descriptor
memory (section D4.4.9).

What's the right API in QEMU to do these guest memory accesses with
the required atomicity guarantees? Currently target/arm uses
address_space_ldq_le(), which turns into a ldq_he_p(), which is
a memcpy(), which I don't think is guaranteed to be a 64-bit load.
And I don't think we have an accessor function for doing an atomic
read-modify-write, do we?

[I think one of the PPC maintainers first brought this issue up on
IRC some while back, but I'm afraid I can't remember who that was.]

thanks
-- PMM

Re: [Qemu-devel] MTTCG and atomicity of loads and stores from QEMU C helper functions

[Richard Henderson]

On 12/15/2017 12:14 PM, Peter Maydell wrote:
> We have a fair amount of code in QEMU which is helper functions
> written in C which make guest memory accesses -- the most common
> case being page table walk code.
> 
> Generally in CPU architectures the accesses by things like the
> page table walker have some atomicity guarantees. For instance
> Arm requires that reads of translation tables are single-copy-atomic
> (v8A Arm ARM rev B.a section B2.2.1). If we supported the
> hardware management of the Access flag (we don't currently) that
> wolud have to be an atomic read-modify-write of the descriptor
> memory (section D4.4.9).
> 
> What's the right API in QEMU to do these guest memory accesses with
> the required atomicity guarantees?

We don't have one, really.

> Currently target/arm uses
> address_space_ldq_le(), which turns into a ldq_he_p(), which is
> a memcpy(), which I don't think is guaranteed to be a 64-bit load.

There are conflicting goals here.  ldq_he_p needs to handle unaligned loads
(which would not be single-copy atomic on any host or guest).

We have also been relying on the compiler to turn a small, fixed size memcpy
into a single instruction on a host that itself supports unaligned loads.
Which happens to be true for x86, armv7, aa64, ppc64, s390x -- i.e. all
supported hosts besides mips and old aa32.

But we can't have it both ways.  We would need separate interfaces to specify
atomic or unaligned, but we can't do both at the same time.

> And I don't think we have an accessor function for doing an atomic
> read-modify-write, do we?

No.  There are some softmmu tcg helpers, but there are no user-only helpers
with the same function signature (there are some case-by-case ifdefs within
target/* to make up for this).  Nor are there accessors for doing atomic rmw on
physical addresses.

There is lots to clean up in this area and it needs some real thought.


r~