[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC v4 02/20] target-arm: Introduce QOM ARMCPUCl
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH RFC v4 02/20] target-arm: Introduce QOM ARMCPUClass |
Date: |
Tue, 13 Mar 2012 18:58:59 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2 |
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! ;)
> 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
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
- [Qemu-devel] [PATCH RFC v4 18/20] target-arm: Add cpuid-{variant, revision} properties to CPU, (continued)
- [Qemu-devel] [PATCH RFC v4 18/20] target-arm: Add cpuid-{variant, revision} properties to CPU, Andreas Färber, 2012/03/10
- [Qemu-devel] [PATCH RFC v4 19/20] target-arm: Simplify pxa270 CPU classes, Andreas Färber, 2012/03/10
- [Qemu-devel] [PATCH RFC v4 17/20] target-arm: Kill off cpu_reset_model_id(), Andreas Färber, 2012/03/10
- [Qemu-devel] [PATCH RFC v4 15/20] target-arm: Store CLIDR in ARMCPUClass, Andreas Färber, 2012/03/10
- [Qemu-devel] [PATCH RFC v4 20/20] hw/integratorcp: Add child property for CPU, Andreas Färber, 2012/03/10
- [Qemu-devel] [PATCH RFC v4 05/20] target-arm: Overwrite reset handler for ti925t, Andreas Färber, 2012/03/10
- [Qemu-devel] [PATCH RFC v4 04/20] target-arm: Prepare model-specific class_init function, Andreas Färber, 2012/03/10
- [Qemu-devel] [PATCH RFC v4 08/20] target-arm: Store cp15 c0_c1 and c0_c2 in ARMCPUClass, Andreas Färber, 2012/03/10
- [Qemu-devel] [PATCH RFC v4 02/20] target-arm: Introduce QOM ARMCPUClass, Andreas Färber, 2012/03/10
- Re: [Qemu-devel] [PATCH RFC v4 02/20] target-arm: Introduce QOM ARMCPUClass, Paolo Bonzini, 2012/03/13
- Re: [Qemu-devel] [PATCH RFC v4 02/20] target-arm: Introduce QOM ARMCPUClass, Peter Maydell, 2012/03/13
- Re: [Qemu-devel] [PATCH RFC v4 02/20] target-arm: Introduce QOM ARMCPUClass, Igor Mitsyanko, 2012/03/14
[Qemu-devel] [PATCH RFC v4 14/20] target-arm: Store VFP MVFR0 and MVFR1 in ARMCPUClass, Andreas Färber, 2012/03/10
[Qemu-devel] [PATCH RFC v4 12/20] target-arm: Move the PXA270's iwMMXt reset to pxa270_reset(), Andreas Färber, 2012/03/10
[Qemu-devel] [PATCH RFC v4 11/20] target-arm: Drop JTAG_ID documentation, Andreas Färber, 2012/03/10
[Qemu-devel] [PATCH RFC v4 16/20] target-arm: Store CCSIDRs in ARMCPUClass, Andreas Färber, 2012/03/10
[Qemu-devel] [PATCH RFC v4 06/20] target-arm: Move CPU feature flags out of CPUState, Andreas Färber, 2012/03/10