After two weeks of running the new QEMU package everything is fine. Moreover I migrated the rest of the guests (both Windows and Linux) to virtio-scsi and no issues so far. I will monitor for another week but this issue seems pretty much fixed!
Kudos to each and everyone of you that helped finding and solving this issue. Fer On jue, feb 28, 2019 at 10:58 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: On Mon, 25 Feb 2019 at 13:06, Peter Maydell <peter.mayd...@linaro.org<mailto:peter.mayd...@linaro.org>> wrote: On Mon, 25 Feb 2019 at 12:22, Natanael Copa <nc...@alpinelinux.org<mailto:nc...@alpinelinux.org>> wrote: > > On Mon, 25 Feb 2019 10:34:23 +0000 > Peter Maydell <peter.mayd...@linaro.org<mailto:peter.mayd...@linaro.org>> wrote: > > The short term fix is to fix your toolchain/compilation > > environment options so that it isn't trying to override > > the definition of memcpy(). > > The easiest workaround is to simply disable FORTIY_SOURCE, but that > will weaken the security for all implemented string functions, strcpy, > memmove etc, so I don't want to do that. > > Is it only lduw_he_p that needs to be atomic or are the other functions > in include/qemu/bswap.h using memcpy also required to be atomic? Hard to say, since we haven't done the "audit all the callers" step that Stefan mentioned. If you're going to replace memcpy with __builtin_memcpy then the safest thing is to do it for all those uses (this will also give you much better generated code for performance purposes). I mentioned this to Richard on IRC the other day, but I think there's a good argument for making upstream QEMU use __builtin_memcpy in these helpers: * it makes us robust against things like this fortify library in the short term (until we fix QEMU to have an equivalent set of functions for doing atomic accesses to AddressSpaces) * 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 thanks -- PMM
