On Tue, Mar 13, 2012 at 8:51 AM, Peter Maydell <peter.maydell at linaro.org> wrote:
> On 13 March 2012 12:36, Christoffer Dall <c.dall at virtualopensystems.com> wrote:
>> + ? ? ? /*
>> + ? ? ? ?* The CP15 c15 register is architecturally implementation
>> + ? ? ? ?* defined, but some guest kernels attempt to read/write a
>> + ? ? ? ?* diagnostics register here. We always return 0 and ignore
>> + ? ? ? ?* writes and hope for the best.
>> + ? ? ? ?*/
>> + ? ? ? { CRn(15), CRm(DF), Op1(DF), Op2(DF), is32, ?WRITE, ignore_write, 1},
>> + ? ? ? { CRn(15), CRm(DF), Op1(DF), Op2(DF), is32, ?READ, ?read_zero, ? ?1},
>> +};
>
> Incidentally, based on bitter experience with QEMU's cp15 emulation,
> I predict that if you have this kind of wide-set default with no
> documentation of exactly which cores need it you'll regret it in
> the future, because you'll end up with a big mess and no idea of
> whether something is wildcarded because of real guests that require
> it or just because somebody was being lazy or because of a mis-read
> TRM or what. I'd encourage you to aim for a model of locking it down
> to "only exactly these registers on exactly this guest core", with
> any deviations from the TRM-documented cp15 registers clearly commented
> as to why they need to be present.
>
Absolutely, but the first cut purpose of this patch was to illustrate
the implementation specifics - we will take care of the specific
emulation aspects afterwards. (Not something to be postponed though,
more like rev 8-9 of the KVM patch series)
> In particular, if we want to support both A9 and A15 guest cores we
> should be doing it explicitly with different sets of cp15 registers
> in each case, rather than defining some vague superset that kinda
> sorta works for the guest kernels we happened to test.
>
yeah this sounds like a plan. We could also simply support a15 for the
moment and be done with a clean solution?
-Christoffer
