Re: [Qemu-devel] [PATCH v1 06/11] target/s390x: cleanup cpu number/address handling

[Cornelia Huck <cohuck@redhat.com>]

On Thu, 31 Aug 2017 18:03:52 +0200
Igor Mammedov <imammedo@redhat.com> wrote:

> On Thu, 31 Aug 2017 16:35:13 +0200
> Cornelia Huck <cohuck@redhat.com> wrote:
> 
> > On Wed, 30 Aug 2017 19:05:56 +0200
> > David Hildenbrand <david@redhat.com> wrote:
> >   
> > > Some time ago we discussed that using "id" as property name is not the
> > > right thing to do, as it is a reserved property for other devices.
> > > 
> > > Switch to the term "addr" instead, which matches the definition in the
> > > PoP called "CPU address". There is no such thing as cpu number, so
> > > rename env.cpu_num to env.cpu_addr.
> > > 
> > > We can get rid of cpu->id now. Keep cpu->index and env->cpu_addr in sync.
> > > cpu->index was already implicitly used by e.g. cpu_exists(), so keeping
> > > both in sync seems to be the right thing to do.
> > > 
> > > cpu->index will now no longer automatically get set via
> > > cpu_exec_realizefn(). For now, we were lucky that both implicitly stayed
> > > in sync.
> > > 
> > > Our new cpu property "addr" can be a static property. Range checks can
> > > be avoided by using the correct type and the "setting after realized"
> > > check is done implicitly.
> > > 
> > > AFAIK, s390x only supports cpu_add and not device_add for cpus. So we
> > > should be able to safely rename that property (no the "id" property
> > > could properly be used for device_add, which needs an artificial id for
> > > identification purposes).    
> this patch seems to somewhat conflicting with
>  https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg06505.html
> that were supposed to go via machine tree and which I've respinned today
> to fix conflicts due just merged pull req.
> 
> Cornelia,
> 
> Could you put/merge it via s390x tree so that David and I work won't clash again?

I can do that, sure. I can put your patch on top of David's.