[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Minimal ARM LPAE support
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] Minimal ARM LPAE support |
Date: |
Tue, 13 Mar 2012 14:21:29 +0000 |
On 13 March 2012 11:19, Alexey Starikovskiy <address@hidden> wrote:
> Minimal ARM LPAE support. Sufficient to boot Linux kernel on vexpress-a15
This is missing chunks of what LPAE ought to mean, which is dubious,
and it doesn't state clearly what it is missing, which is definitely
a problem.
> +void HELPER(set_cp15_64)(CPUState *env, uint32_t insn, uint64_t val)
> +{
> + int crm = insn & 0xf;
> + int opc1 = (insn >> 4) & 0xf;
> + if (crm == 2) {
> + switch (opc1) {
> + case 0:
> + env->cp15.c2_base0 = val;
> + tlb_flush(env, 0); // might change ASID
> + return;
> + case 1:
> + env->cp15.c2_base1 = val;
> + tlb_flush(env, 0); // might change ASID
> + return;
> + default:;
> + }
> + } else if (crm == 7) {
> + if (opc1 == 0) {
> + env->cp15.c7_par = val;
> + return;
> + }
> + }
> + cpu_abort(env, "Unimplemented cp15 register 64bit write (c%d[%d])\n",
> crm, opc1);
> +}
This is aiming 64 bit cp15 handling for the same swamp in which
32 bit cp15 is currently stuck. At a bare minimum, this must do
complete decoding of all the crn/crm/opc fields, and must restrict
register implementations to only CPUs where they exist (ie check
ARM_FEATURE_LPAE).
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -2559,17 +2559,9 @@ static int disas_cp15_insn(CPUState *env,
> DisasContext *s, uint32_t insn)
>
> /* M profile cores use memory mapped registers instead of cp15. */
> if (arm_feature(env, ARM_FEATURE_M))
> - return 1;
> + return 1;
>
> - if ((insn & (1 << 25)) == 0) {
> - if (insn & (1 << 20)) {
> - /* mrrc */
> - return 1;
> - }
> - /* mcrr. Used for block cache operations, so implement as no-op.
> */
This change seems to drop the MCRR block cache op handling and I don't
see anything elsewhere which implements it. This will presumably break
some CPU/guest combination.
More general question -- should we move target_phys_addr_t to a 64
bit type?
-- PMM