On Wed, Nov 8, 2017 at 1:52 PM, Eduardo Habkost <ehabk...@redhat.com> wrote: > On Wed, Nov 08, 2017 at 10:29:43PM +0100, Richard Henderson wrote: >> On 11/06/2017 09:13 PM, Emilio G. Cota wrote: >> > Subject: [PATCH] qom: move CPUClass.tcg_initialize to a global >> > >> > 55c3cee ("qom: Introduce CPUClass.tcg_initialize", 2017-10-24) >> > introduces a per-CPUClass bool that we check so that the target CPU >> > is initialized for TCG only once. This works well except when >> > we end up creating more than one CPUClass, in which case we end >> > up incorrectly initializing TCG more than once, i.e. once for >> > each CPUClass. >> > >> > This can be replicated with: >> > $ aarch64-softmmu/qemu-system-aarch64 -machine xlnx-zcu102 -smp 6 \ >> > -global driver=xlnx,,zynqmp,property=has_rpu,value=on >> > In this case the class name of the "RPUs" is prefixed by "cortex-r5-", >> > whereas the "regular" CPUs are prefixed by "cortex-a53-". This >> > results in two CPUClass instances being created. >> > >> > Fix it by introducing a static variable, so that only the first >> > target CPU being initialized will initialize the target-dependent >> > part of TCG, regardless of CPUClass instances. >> >> Hah! >> >> So, I had been thinking of the xylinx ARM + Microblaze case, where we really >> do >> need two different initializations. I never imagined that two different ARM >> parts had different CPUClasses. > > Is xylinx ARM + Microblaze something that already works (and > would be broken by this patch), or something planned for the > future?
Something planned for the future, it has never worked. Alistair > >> >> So I guess it's my initial patch that unified this that's more buggy than >> not. > > We still have the option of reverting the original patch, but (if > it doesn't break anything) this patch looks like a simpler fix > for 2.11 than a full revert. > > -- > Eduardo >