On Fri, 23 Nov 2018 at 18:24, Eduardo Habkost <ehabk...@redhat.com> wrote: > > On Fri, Nov 23, 2018 at 06:14:28PM +0000, Peter Maydell wrote: > > 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?
It would be internal to QEMU (not exposed to the guest or to the user), yes. > 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. I see, thanks. My other question about this code was a slightly different one -- are we guaranteed to be holding the iothread lock when we create new QOM objects? (ie that we won't have races between two threads which both try to create new objects and increment the variable) thanks -- PMM
