qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH arm-midr v2 1/2] ARM: Convert MIDR to a property


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH arm-midr v2 1/2] ARM: Convert MIDR to a property
Date: Sun, 19 Jan 2014 11:46:55 +1000

On Sun, Jan 19, 2014 at 11:12 AM, Peter Maydell
<address@hidden> wrote:
> On 19 January 2014 00:59, Peter Crosthwaite
> <address@hidden> wrote:
>> Do you even need this now? The normal arrayified dc->props properties
>> are added at device::init time. As TYPE_DEVICE is a parent class, its
>> init function is called before CPUs (normal inits are called in
>> parent->child order, the post_inits are reverse). This means the
>> cpu::init fns should correctly set the device-specific default after
>> device::init, trampling the bogus default defined in the property
>> array.
>>
>> All of this however assumes that MIDR is unconditionally existent for
>> all ARMCPU. Peter, are you able to confirm that thats ok before we
>> commit to this implementation over the conditional post_init approach?
>
> IIRC ARMv4 and earlier didn't define the MIDR, but we don't
> actually emulate any of those. In general, my intent with all these
> constant fields in the ARMCPU struct was that we'd end up making
> them just properties available on all ARMCPU objects, and if the
> particular subtype of ARMCPU happened not to have FP and so
> didn't need the reset_fpsid, for example, it would just ignore whatever
> value you set the property to. I don't think we need to tie ourselves
> in knots to restrict the properties to particular CPUs if it is too
> implementationally awkward (though it would be nice if we can
> tie them to ARM_FEATURE_* bits for more or less free).
>

ARM_FEATURE_V5 exists. Will that do the job? That will exclude just
the V4T AFAICT. Worth bothering?

Regards,
Peter

> thanks
> -- PMM
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]