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

[Fernando Casas Schössow]

I’m running the test guest on another host for the last three days and so far 
so good.
Yet because of the nature of this bug/issue it can take a few hours or a few 
days more to fail. The failure is unpredictable.

Does it make sense to continue running the guest on this different host to try 
to repro or can I migrate the guest back to the original host? At this point I 
don’t think it will make any difference. The current host storage is far more 
slower causing latency issues to the guest so if I can migrate it back it would 
be great.

Sent from my iPhone

> On 25 Feb 2019, at 11:34, Peter Maydell <address@hidden> wrote:
> 
>> On Mon, 25 Feb 2019 at 10:24, Natanael Copa <address@hidden> wrote:
>> 
>> On Sat, 23 Feb 2019 16:18:15 +0000
>> Peter Maydell <address@hidden> wrote:
>> 
>>>> On Sat, 23 Feb 2019 at 16:05, Natanael Copa <address@hidden> wrote:
>>>> I was thinking of something in the lines of:
>>>> 
>>>> typedef volatile uint16_t __attribute__((__may_alias__)) volatile_uint16_t;
>>>> static inline int lduw_he_p(const void *ptr)
>>>> {
>>>>     volatile_uint16_t r = *(volatile_uint16_t*)ptr;
>>>>     return r;
>>>> }
>>> 
>>> This won't correctly handle accesses with unaligned pointers,
>>> I'm afraid. We rely on these functions correctly working
>>> with pointers that are potentially unaligned.
>> 
>> Well, current code does not even handle access with aligned pointers,
>> depending on FORTIFY_SOURCE implementation.
> 
> It correctly handles aligned and unaligned pointers for the
> API guarantees that the function in QEMU provides, which is
> to say "definitely works on any kind of aligned or unaligned
> pointer, not guaranteed to be atomic". Unfortunately some
> code in QEMU is implicitly assuming it is atomic, which this
> QEMU function does not guarantee -- it just happens to provide
> that most of the time.
> 
>> My thinking here is that we depend on assumption that compiler will
>> remove the memcpy call, so maybe find other way to generate same
>> assembly, while still depend on compiler optimization.
> 
>> I did some tests and compared the assembly output. The compiler will
>> generate same assembly if volatile is not used. The attribute
>> __may_alias__ does not seem to make any difference. So the following
>> function generates exactly same assembly:
>> 
>> static inline int lduw_he_p(const void *ptr)
>> {
>>        uint16_t r = *(uint16_t*)ptr;
>>        return r;
>> }
> 
> This still is not guaranteed to work on unaligned pointers.
> (For instance it probably won't work on SPARC hosts.)
> More generally there is no way to have a single function
> that is guaranteed to handle unaligned pointers and also
> guaranteed to produce an atomic access on all host architectures
> that we support, because not all host architectures allow
> you to do both with the same instruction sequence. So
> you can't just change this function to make it provide
> atomic access without breaking the other guarantee it is
> providing.
> 
> The long term fix for this is that we need to separate out
> our APIs so we can have a family of functions that guarantee
> to work on unaligned pointers, and a family that guarantee
> to work atomically, and calling code can use the one that
> provides the semantics it requires.
> 
> The short term fix is to fix your toolchain/compilation
> environment options so that it isn't trying to override
> the definition of memcpy().
> 
> thanks
> -- PMM