Re: [PATCH qemu v3 1/2] target/arm: Handle IC IVAU to improve compatibility with JITs

["John Högberg" <john.hogberg@ericsson.com>]

> This is implementation-dependent : if the
> implementation reports CTR_EL0.{DIC,IDC} == {1,1} then
> it doesn't need icache invalidation or data cache clean
> to provide data-to-instruction or instruction-to-data
> coherence. This is currently not true for any CPU QEMU
> models, but the Neoverse-V1 (which I'm about to send a patch
> for) can do this. (It's also tempting to make 'max' set
> these bits, which would save the guest some effort in
> doing cache ops which we NOP anyway.)

Sure, I'll update the commit message to this effect.

> So maybe we should also force CTR_EL0.DIC to 0 in user-mode
> so that the guest won't decide based on the value of that bit
> that it doesn't need to issue the IC IVAU ?
> arm_cpu_realizefn() would be the place to do this, I think.

Sounds good, I'll fix that. Thanks :)

/John

-----Original Message-----
From: Peter Maydell <peter.maydell@linaro.org>
To: ~jhogberg <john.hogberg@ericsson.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH qemu v3 1/2] target/arm: Handle IC IVAU to improve
compatibility with JITs
Date: Mon, 26 Jun 2023 13:38:16 +0100

On Tue, 20 Jun 2023 at 02:04, ~jhogberg <jhogberg@git.sr.ht> wrote:
> 
> From: John Högberg <john.hogberg@ericsson.com>
> 
> Unlike architectures with precise self-modifying code semantics
> (e.g. x86) ARM processors do not maintain coherency for instruction
> execution and memory, and require the explicit use of cache
> management instructions as well as an instruction barrier to make
> code updates visible (the latter on every core that is going to
> execute said code).

This is implementation-dependent : if the
implementation reports CTR_EL0.{DIC,IDC} == {1,1} then
it doesn't need icache invalidation or data cache clean
to provide data-to-instruction or instruction-to-data
coherence. This is currently not true for any CPU QEMU
models, but the Neoverse-V1 (which I'm about to send a patch
for) can do this. (It's also tempting to make 'max' set
these bits, which would save the guest some effort in
doing cache ops which we NOP anyway.)

So maybe we should also force CTR_EL0.DIC to 0 in user-mode
so that the guest won't decide based on the value of that bit
that it doesn't need to issue the IC IVAU ?
arm_cpu_realizefn() would be the place to do this, I think.

thanks
-- PMM