Re: [Qemu-devel] [PATCH RFC v4 02/20] target-arm: Introduce QOM ARMCPUClass

[Igor Mitsyanko]

On 03/13/2012 09:58 PM, Andreas Färber wrote:

Am 13.03.2012 13:31, schrieb Igor Mitsyanko:

On 03/10/2012 08:53 PM, Andreas Färber wrote:

diff --git a/target-arm/cpu.c b/target-arm/cpu.c
new file mode 100644
index 0000000..dabc094
--- /dev/null
+++ b/target-arm/cpu.c

[...]

+static void cpu_register(const ARMCPUInfo *info)
+{
+    TypeInfo type = {
+        .name = info->name,
+        .parent = TYPE_ARM_CPU,
+        .instance_size = sizeof(ARMCPU),
+        .class_size = sizeof(ARMCPUClass),
+        .class_init = arm_cpu_class_init,
+        .class_data = (void *)info,
+    };

Are non-initialized members guaranteed to be zero here?

I thought so for the C99-style struct initialization... I never ran into
crashes while testing. Do we need static to be safe?

+    type_register_static(&type);
+}
+

Probably should be type_register() here in case these two will actually
differ in the future.

My thinking was we don't need it here because the data (esp. strings)
are not dynamically allocated. By comparison, I used type_register() for
-cpudef in target-i386, I believe.

But I really guess it's a bug that they're just an alias right now! ;)

Object.h states we need to use type_register_static() only when TypeInfo exists for the lifetime of
Type. As I understand this, TypeInfo must have static const storage qualifier when used with type_register_static() and can have automatic storage qualifier when used with type_register().
Maybe in the future type_register_static() will just copy a pointer to string variables of passed
TypeInfo instead of g_strdup() them, then your code wouldn't work as expected.

If this information is of any help, we've got no problems when emulating
ARM-based Exynos boards in QEMU with this whole patchset applied.

Thanks a lot for testing!

Have you thought about how to QOM'ify your boards? Mid-term I'd like to
see an "exynos4210" object with the CPUs on it - maybe "cpu[0]" and
"cpu[1]" child properties? Or "core[x]"? I had played with the sh7750 a
bit on my branch but like the arm926 it's a single-core.

Andreas

Yes, we've done some work on this, but we are waiting to see how you want to proceed with SoC
QOM type, and if you're going to introduce it at all. Personally I have no idea what members and
methods a general SoC type could have.
And another question, should we somehow exploit a fact that majority of peripheral devices on
SoCs share i/o ports with each other and only a handful of them are actually active at the same
time. Currently we instantiate all SoC devices even if half of them are not used in emulated configuration. Maybe we should dynamically create/destroy devices depending on runtime GPIO
configuration, or make all devices a board's child instead of SoC's child. Not sure that it's worth an effort though.

As for CPU's object, Peter's idea with CortexA9 and core1, core2 childs looks good to me.

-- 
Mitsyanko Igor
ASWG, Moscow R&D center, Samsung Electronics
email: address@hidden