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: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PULL 1/6] audio/hda: create millisecond timers that handle IO
Date: Wed, 27 Jun 2018 08:51:26 +0200
User-agent: NeoMutt/20180622

> > 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?

cheers,
  Gerd




reply via email to

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