On Fri, Nov 23, 2018 at 06:53:07PM +0000, Peter Maydell wrote: > 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)
I assume we are, because type_initialize() (called by object_new()) isn't thread-safe. -- Eduardo
