On Mon, 18 Mar 2019 at 17:07, Paolo Bonzini <pbonz...@redhat.com> wrote: > > On 18/03/19 12:29, Peter Maydell wrote: > > In the accessor functions ld*_he_p() and st*_he_p() we use memcpy() > > to perform a load or store to a pointer which might not be aligned > > for the size of the type. We rely on the compiler to optimize this > > memcpy() into an efficient load or store instruction where possible. > > This is required for good performance, but at the moment it is also > > required for correct operation, because some users of these functions > > require that the access is atomic if the pointer is aligned, which > > will only be the case if the compiler has optimized out the memcpy(). > > (The particular example where we discovered this is the virtio > > vring_avail_idx() which calls virtio_lduw_phys_cached() which > > eventually ends up calling lduw_he_p().) > > > > Unfortunately some compile environments, such as the fortify-source > > setup used in Alpine Linux, define memcpy() to a wrapper function > > in a way that inhibits this compiler optimization. > > > > The correct long-term fix here is to add a set of functions for > > doing atomic accesses into AddressSpaces (and to other relevant > > families of accessor functions like the virtio_*_phys_cached() > > ones), and make sure that callsites which want atomic behaviour > > use the correct functions. > > > > In the meantime, switch to using __builtin_memcpy() in the > > bswap.h accessor functions. This will make us robust against things > > like this fortify library in the short term. In the longer term > > it will mean that we don't end up with these functions being really > > badly-performing even if the semantics of the out-of-line memcpy() > > are correct. > > > > Reported-by: Fernando Casas Schössow <casasferna...@outlook.com> > > Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
> Queued, thanks. Ping? This hasn't hit master yet, and today is the last day for rc3 which I'm hoping might be the last rc for 4.0... thanks -- PMM
