Re: [Qemu-devel] [PULL for-2.5 2/4] block: Don't wait serialising for non-COR read requests

[Christian Borntraeger <borntraeger@de.ibm.com>]

On 12/08/2015 03:10 PM, Kevin Wolf wrote:
[...]
>>>> Not a compiler bug. gcc uses a floating point register 8 to spill
>>>> the pointer of blk (which is call saved) submit_request will later
>>>> on call  qemu_coroutine_enter and after returning from 
>>>> qemu_coroutine_enter, the fpr8 contains junk. Not sure yet, what happened.
>>>
>>> Coroutines don't save the FPU state, so you're not supposed to use
>>> floating point operations inside coroutines. That the compiler spills
>>> some integer value into a floating point register is a bit nasty...
>>
>> Just checked.  bdrv_aligned_preadv does also use fprs (also for filling
>> and spilling). Some versions of gcc seem to like that as the LDGR and LGDR
>> instructions are pretty cheap and move the content from/to fprs in a bitwise
>> fashion. So this coroutine DOES trash floating point registers.
>>
>> Without the patch gcc seems to be fine with the 16 gprs and does not
>> spilling/filling from/to fprs in bdrv_aligned_preadv.
> 
> Actually, on closer look it seems that the reason why there is no code
> for saving the floating point registers in setjmp() on x86 is that they
> are caller-save registers anyway, so it doesn't have to. Otherwise the
> internet seems to be of the opinion that longjmp() must indeed restore
> floating point registers.
> 
> So this might be a libc bug on s390 then.

Fixed with 
https://sourceware.org/ml/libc-alpha/2013-01/msg00853.html

Christian