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~