On Fri, Nov 23, 2018 at 06:14:28PM +0000, Peter Maydell wrote:
> On Fri, 23 Nov 2018 at 18:11, Eduardo Habkost <ehabk...@redhat.com> wrote:
> > On Fri, Nov 23, 2018 at 10:17:14AM +0100, Luc Michel wrote:
> > > This commit adds the cpu-cluster type. It aims at gathering CPUs from
> > > the same cluster in a machine.
> > >
> > > For now it only has a `cluster-id` property.
> > >
> > > Signed-off-by: Luc Michel <luc.mic...@greensocs.com>
> > > Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
> > > Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com>
> > > Tested-by: Philippe Mathieu-Daudé <phi...@redhat.com>
> > > Reviewed-by: Edgar E. Iglesias <edgar.igles...@xilinx.com>
> > [...]
> > > +static void cpu_cluster_init(Object *obj)
> > > +{
> > > + static uint32_t cluster_id_auto_increment;
> > > + CPUClusterState *cluster = CPU_CLUSTER(obj);
> > > +
> > > + cluster->cluster_id = cluster_id_auto_increment++;
> >
> > I see that you implemented this after a suggestion from Philippe,
> > but I'm worried about this kind of side-effect on object/device
> > code. I'm afraid this will bite us back in the future. We were
> > bitten by problems caused by automatic cpu_index assignment on
> > CPU instance_init, and we took a while to fix that.
> >
> > If you really want to do this and assign cluster_id
> > automatically, please do it on realize, where it won't have
> > unexpected side-effects after a simple `qom-list-properties` QMP
> > command.
> >
> > I would also add a huge warning above the cluster_id field
> > declaration, mentioning that the field is not supposed to be used
> > for anything except debugging. I think there's a large risk of
> > people trying to reuse the field incorrectly, just like cpu_index
> > was reused for multiple (conflicting) purposes in the past.
>
> One thing I would like to do with this new "cpu cluster"
> concept is to use it to handle a problem we have at the
> moment with TCG, where we assume all CPUs have the same
> view of physical memory (and so if CPU A executes from physical
> address X it can share translated code with CPU B executing
> from physical address X). The idea is that we should include
> the CPU cluster number in the TCG hash key that we use to
> look up cached translation blocks, so that only CPUs in
> the same cluster (assumed to have the same view of memory
> and to be identical) share TBs.
>
> If we don't have a unique integer key for the cluster, what
> should we use instead ?
This sounds like a reasonable use of cluster_id as implemented in
this patch. The ID would be only used internally and not exposed
to the outside, right?
I'm more worried about cases where we could end up exposing the
ID in an external interface (either to guests, or through QMP or
the command-line). This happened to cpu_index and we took a long
time to fix the mess.
--
Eduardo
