[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] Guest unresponsive after Virtqueue size ex
From: |
Fernando Casas Schössow |
Subject: |
Re: [Qemu-devel] [Qemu-block] Guest unresponsive after Virtqueue size exceeded error |
Date: |
Thu, 7 Mar 2019 07:14:38 +0000 |
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
- Re: [Qemu-devel] [Qemu-block] Guest unresponsive after Virtqueue size exceeded error,
Fernando Casas Schössow <=