Re: [Qemu-devel] [Qemu-block] Guest unresponsive after Virtqueue size exceeded error

[Fernando Casas Schössow]

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 <address@hidden> wrote:
On Mon, 25 Feb 2019 at 13:06, Peter Maydell 
<address@hidden<mailto:address@hidden>> wrote:
On Mon, 25 Feb 2019 at 12:22, Natanael Copa 
<address@hidden<mailto:address@hidden>> wrote: > > On Mon, 25 Feb 2019 10:34:23 
+0000 > Peter Maydell <address@hidden<mailto:address@hidden>> 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