Re: [Qemu-devel] [PATCH v3 5/5] spapr: fix migration of ICPState objects from/to older QEMU

[Greg Kurz]

On Tue, 13 Jun 2017 11:12:17 +0100
"Dr. David Alan Gilbert" <address@hidden> wrote:
[...]
> > > > > 
> > > > > So what's the problem with a (void *)i ?    
> > > > 
> > > > https://stackoverflow.com/questions/8618637/what-does-it-mean-to-convert-int-to-void-or-vice-versa
> > > >    
> > > > > It's simple, as long as you're
> > > > > not actually using the opaque anywhere it's easy.
> > > > >     
> > > > 
> > > > but as you say, since the opaque isn't used anywhere, it is probably
> > > > okay to pass (void *) i.    
> > > 
> > > Yes, I don't think we're ever casting back from the (void *) to an int
> > > so it feels pretty safe to me.
> > >   
> > 
> > Just one nit, gcc doesn't like it on 64-bit hosts:
> > 
> > hw/ppc/spapr.c: In function ‘pre_2_10_vmstate_register_dummy_icp’:
> > hw/ppc/spapr.c:148:60: error: cast to pointer from integer of different
> >  size [-Werror=int-to-pointer-cast]
> >      vmstate_register(NULL, i, &pre_2_10_vmstate_dummy_icp, (void *) i);
> > 
> > I need to cast to (long) first.  
> 
> Try casting to a uintptr_t first.
> 

Yeah, you're right. The standard doesn't guarantees whether pointers
have the size of int or long. I'll use intptr_t.

Thanks for the suggestion.

> Dave
> 
> > > >     
> > > > > Note from a quick glance at your patch;  will this work migrating
> > > > > from this 2.10 -> 2.9 ?  Are your dummy vmstate's really good enough 
> > > > > for
> > > > > the 2.9 ?
> > > > >     
> > > > 
> > > > Yeah but I need to add some comments as David suggested.
> > > > 
> > > > The idea is that 2.9 used to create a bunch of objects at machine init,
> > > > that only get used when CPUs are plugged. With 2.10, these objects are
> > > > now created under the CPUs. When migrating from 2.10 to 2.9, we only 
> > > > need
> > > > to send the real objects. The dummy vmstate entries don't send anything
> > > > (.needed always returns false) since the corresponding objects in 2.9 
> > > > aren't
> > > > being used and still have their default state.
> > > >     
> > > 
> > > OK, that'll probably work.
> > >   
> > 
> > Thanks for this confirmation.
> >   
> > > Dave
> > >   
> > > > > Dave
> > > > > 
> > > > >     
> > > > > > --
> > > > > > Greg      
> > > > > 
> > > > > 
> > > > > --
> > > > > Dr. David Alan Gilbert / address@hidden / Manchester, UK    
> > > >     
> > > 
> > > 
> > > --
> > > Dr. David Alan Gilbert / address@hidden / Manchester, UK  
> >   
> 
> 
> --
> Dr. David Alan Gilbert / address@hidden / Manchester, UK

pgpAGEP41V7xA.pgp
Description: OpenPGP digital signature