qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Starikovskiy <aystarik@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Minimal ARM LPAE support
Date: Tue, 13 Mar 2012 18:51:59 +0400	[thread overview]
Message-ID: <4F5F5F0F.2070206@gmail.com> (raw)
In-Reply-To: <CAFEAcA_4fFR9VDDF=Xe6S4yyMqPNF1e-xydZigVozfDXZSXVqQ@mail.gmail.com>

On 03/13/2012 06:21 PM, Peter Maydell wrote:
> On 13 March 2012 11:19, Alexey Starikovskiy<aystarik@gmail.com>  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.
>
I've cut out Virtualization, TrustZone, shareable/cache attributes.
Also, as you've mentioned later, phys_address is still 32 bits, so we really can't get more memory than before.
>> +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).
>
As it is a helper for MCRR, only crm and opc1 fields are present in instruction. All allowed values are checked.
I'll need to check how MCRR to these registers will behave if LPAE is not featured
>> --- 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.
Do you have any pointer on that exactly did we try to emulate here?
> More general question -- should we move target_phys_addr_t to a 64
> bit type?
It could be done later on, for now it works as is. Making it 64 bit breaks DMA in pxa*, so I'm not sure how to do that properly.

Thanks,
Alex.

  reply	other threads:[~2012-03-13 14:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-13 11:19 [Qemu-devel] Minimal ARM LPAE support Alexey Starikovskiy
2012-03-13 13:45 ` Mark Langsdorf
2012-03-13 14:21 ` Peter Maydell
2012-03-13 14:51   ` Alexey Starikovskiy [this message]
2012-03-13 15:14     ` Peter Maydell
2012-03-13 15:27       ` Alexey Starikovskiy
2012-03-13 15:50         ` Peter Maydell
2012-03-13 17:21           ` [Qemu-devel] [PATCH 0/3] " Alexey Starikovskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F5F5F0F.2070206@gmail.com \
    --to=aystarik@gmail.com \
    --cc=paul@codesourcery.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).