qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Save/load PC speaker internal state (v2)


From: Pavel Dovgaluk
Subject: Re: [Qemu-devel] [PATCH] Save/load PC speaker internal state (v2)
Date: Wed, 29 Aug 2012 11:05:29 +0400

> -----Original Message-----
> From: Jan Kiszka [mailto:address@hidden
> Sent: Tuesday, August 28, 2012 11:13 AM
> To: Pavel Dovgaluk
> Cc: 'qemu-devel'
> Subject: Re: [PATCH] Save/load PC speaker internal state (v2)
> 
> On 2012-08-28 08:58, Pavel Dovgaluk wrote:
> > Save PC speaker state to remove differences between system
> > states after saving the snapshot and after loading it again.
> > This patch is needed for deterministic replay of the execution.
> >
> > v2: Do not save the data that cannot affect the guest code behavior.
> >
> > Signed-off-by: Pavel Dovgalyuk<address@hidden>
> > ---
> >  hw/pcspk.c |   17 +++++++++++++++--
> >  1 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/pcspk.c b/hw/pcspk.c
> > index e430324..07a3de0 100644
> > --- a/hw/pcspk.c
> > +++ b/hw/pcspk.c
> > @@ -46,8 +46,8 @@ typedef struct {
> >      unsigned int pit_count;
> >      unsigned int samples;
> >      unsigned int play_pos;
> > -    int data_on;
> > -    int dummy_refresh_clock;
> > +    uint8_t data_on;
> > +    uint8_t dummy_refresh_clock;
> >  } PCSpkState;
> >
> >  static const char *s_spk = "pcspk";
> > @@ -159,6 +159,18 @@ static const MemoryRegionOps pcspk_io_ops = {
> >      },
> >  };
> >
> > +static const VMStateDescription vmstate_spk = {
> > +    .name = "pcspk",
> > +    .version_id = 1,
> > +    .minimum_version_id = 1,
> > +    .minimum_version_id_old = 1,
> > +    .fields      = (VMStateField[]) {
> > +        VMSTATE_UINT8(data_on, PCSpkState),
> > +        VMSTATE_UINT8(dummy_refresh_clock, PCSpkState),
> 
> Just to understand the plan: The intention is to leave the audio
> disabled after resume, just saving those bits that can be read back via
> IO port, correct? Then please document this in a comment, otherwise fix it.

  The plan is to make guest system behavior deterministic.
  Resuming the audio is not needed for this but could be a useful side effect.
  I thought about solutions of this problem and got the following:
we cannot reinitialize the buffer in post_load function, because pit used for
samples generation could be not reloaded yet at that moment and the buffer's 
state
will be invalid in this case.
  So the only solution is saving and loading the complete state of the audio 
buffer.

Pavel Dovgaluk





reply via email to

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