qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 1/6] audio/hda: create millisecond timers that ha


From: Thomas Huth
Subject: Re: [Qemu-devel] [PULL 1/6] audio/hda: create millisecond timers that handle IO
Date: Wed, 27 Jun 2018 09:24:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 27.06.2018 08:51, Gerd Hoffmann wrote:
>>> Signed-off-by: Martin Schrodt <address@hidden>
>>> Signed-off-by: Gerd Hoffmann <address@hidden>
>>> Message-id: address@hidden
>>> Message-id: address@hidden
>>>
>>> [ kraxel: keep old code for compatibility with older qemu versions,
>>>           add property to switch code paths at runtime ]
>>> [ kraxel: new code is disabled by default, use-timer=on enables it ]
>>>
>>> Signed-off-by: Gerd Hoffmann <address@hidden>
>>> ---
>>>  hw/audio/hda-codec.c | 263 
>>> ++++++++++++++++++++++++++++++++++++++++++++++-----
>>>  hw/audio/intel-hda.c |   7 --
>>>  2 files changed, 237 insertions(+), 33 deletions(-)
>>
>> This patch breaks compilation on clang with -m32 for me, because I
>> apparently I don't have 64 bit atomics there.  Should there be
>> CONFIG_ATOMIC64 guards and handling for when that isn't defined?
> 
> Given the code runs under big qemu lock anyway the atomics are not
> needed, so we could drop just them.  I left them in nevertheless because
> 
>   (a) we might want try run the code in a thread instead of using a timer, and
>   (b) I was too lazy to rewrite the code to drop the atomics.
> 
> I'd prefer to keep option (a) ...
> 
> Using int32_t instead of int64_t for rpos and wpos would be another way.
> Also not that great because they will wrap then after playing sound for
> roughly 6 hours.
> 
> Using int32_t on 32bit hosts only (or depending on CONFIG_ATOMIC64) is
> bad too because rpos and wpos are in vmstate, so the live migration
> stream format changes.
> 
> Hmm.
> 
> Drop support for 32bit hosts in qemu?

I guess the only way to answer that question reliably is to send a patch
to mark 32-bit hosts as deprecated...

Anyway, you still have got to fix that problem with -m32 now somehow
since we certainly can not drop 32-bit immediately.

 Thomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]