qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 10/21] acpi_piix4: add infrastructure to send CP


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 10/21] acpi_piix4: add infrastructure to send CPU hot-plug GPE to guest
Date: Tue, 23 Apr 2013 18:01:56 +0300

On Tue, Apr 23, 2013 at 04:51:36PM +0200, Igor Mammedov wrote:
> On Tue, 23 Apr 2013 16:04:22 +0300
> "Michael S. Tsirkin" <address@hidden> wrote:
> 
> > On Tue, Apr 23, 2013 at 02:54:16PM +0200, Igor Mammedov wrote:
> > > On Tue, 23 Apr 2013 13:38:10 +0200
> > > Juan Quintela <address@hidden> wrote:
> > > 
> > > > Igor Mammedov <address@hidden> wrote:
> > > > 
> > > > >  
> > > > > +#define VMSTATE_CPU_STATUS_ARRAY(_field,
> > > > > _state)                             \
> > > > > +
> > > > > {                                                                     
> > > > >       \
> > > > > +     .name       =
> > > > > (stringify(_field)),                                      \
> > > > > +     .version_id = 0,
> > > > > \
> > > > 
> > > > this line should be:
> > > >    .version_id = 4, 
> > > > 
> > > > 
> > > > > +     .num        =
> > > > > PIIX4_PROC_LEN,                                           \
> > > > > +     .info       =
> > > > > &vmstate_info_uint8,                                      \
> > > > > +     .size       =
> > > > > sizeof(uint8_t),                                          \
> > > > > +     .flags      =
> > > > > VMS_ARRAY,                                                \
> > > > > +     .offset     = vmstate_offset_array(_state, _field,
> > > > > uint8_t,             \
> > > > > +
> > > > > PIIX4_PROC_LEN),                     \
> > > > > + }
> > > > > +
> > > > >  /* qemu-kvm 1.2 uses version 3 but advertised as 2
> > > > >   * To support incoming qemu-kvm 1.2 migration, change version_id
> > > > >   * and minimum_version_id to 2 below (which breaks migration from
> > > > 
> > > > > @@ -265,7 +289,7 @@ static int acpi_load_old(QEMUFile *f, void
> > > > > *opaque, int version_id) */
> > > > >  static const VMStateDescription vmstate_acpi = {
> > > > >      .name = "piix4_pm",
> > > > > -    .version_id = 3,
> > > > > +    .version_id = 4,
> > > > >      .minimum_version_id = 3,
> > > > >      .minimum_version_id_old = 1,
> > > > >      .load_state_old = acpi_load_old,
> > > > > @@ -281,6 +305,7 @@ static const VMStateDescription vmstate_acpi = {
> > > > >          VMSTATE_STRUCT(ar.gpe, PIIX4PMState, 2, vmstate_gpe,
> > > > > ACPIGPE), VMSTATE_STRUCT(pci0_status, PIIX4PMState, 2,
> > > > > vmstate_pci_status, struct pci_status),
> > > > > +        VMSTATE_CPU_STATUS_ARRAY(gpe_cpu.sts, PIIX4PMState),
> > > > 
> > > > It is more,  I think that simply:
> > > > 
> > > > VMSTATE_UINT8_ARRAY_V(gpu_cpu.sts,  PIIX4PMstate, PIIX4_PROC_LEN,  4);
> > > > 
> > > > Should do the trick without the previous blob (it was needed for the old
> > > > version because we have a uint32 data but we send a uint16 one).
> > > > 
> > > > Could you check?  I don't have an easy way to test that it "receives"
> > > > the right value.
> > > Just checked, it works with VMSTATE_UINT8_ARRAY_V as well,
> > > 
> > > but I have a question, why version should be 4, looking at git history
> > > components of vmstate_acpi don't advance their version each time
> > > vmstate_acpi change, they do it only when they themselves change.
> > 
> > Generally changing version breaks cross version migration.
> > So please don't do it for an optional
> > feature like CPU hotplug.
> I probably wasn't clear enough, question was about why a new component
> VMSTATE_UINT8_ARRAY_V(gpu_cpu.sts, ...) should be version 4 and not 0?
> 
> As for advancing vmstate_acpi version, it was requested:
> http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg04775.html

It says
        You need to either bump the version, or add a subsection.   The
        subsection is not needed until the first hot-(un)plug action.
please add a subsection, don't bump the version :)

> 
> 
> Anyway why chatting on IRC with Juan, question arises:
> Do we really need to save/restore gpe_cpu.sts field?
> 
> Since target has to be started with all CPUs (including hot-plugged), it will
> have the same gpe_cpu.sts bitmap.
> 
> > > > 
> > > > Later,  Juan.
> > > > 
> > > > >          VMSTATE_END_OF_LIST()
> > > > >      }
> > > > >  };
> > > > > @@ -585,6 +610,85 @@ static const MemoryRegionOps piix4_pci_ops = {
> > > > 
> > 



reply via email to

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