Re: [Qemu-devel] [PATCH for-4.0] include/qemu/bswap.h: Use __builtin_memcpy() in accessor functions

[Peter Maydell]

On Mon, 18 Mar 2019 at 17:07, Paolo Bonzini <address@hidden> 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 <address@hidden>
> > Signed-off-by: Peter Maydell <address@hidden>


> 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