qemu-devel
[Top][All Lists]
Advanced

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

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


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v1 06/11] target/s390x: cleanup cpu number/address handling
Date: Thu, 31 Aug 2017 18:03:52 +0200

On Thu, 31 Aug 2017 16:35:13 +0200
Cornelia Huck <address@hidden> wrote:

> On Wed, 30 Aug 2017 19:05:56 +0200
> David Hildenbrand <address@hidden> 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?



reply via email to

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