Re: [Xen-devel] [PATCH] arm/monitor: flush the icache during SMC traps

[Julien Grall <julien.grall@xxxxxxx>]

Hi Tamas,

On 25/01/2017 20:02, Tamas K Lengyel wrote:
> During an SMC trap it is possible that the user may change the memory
By user, do you mean the monitor application?

> from where the SMC was fetched. However, without flushing the icache
> the SMC may still trigger if the pCPU was idle during the trap. Flush
> the icache to ensure consistency.
invalidate_icache will invalidate the cache to PoU on all the pCPUs. But 
here you only mention a problem on the current pCPU. So which behavior 
do you want to achieve?
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
> ---
> Cc: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
> Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> Cc: Julien Grall <julien.grall@xxxxxxx>
> ---
>  xen/arch/arm/monitor.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/xen/arch/arm/monitor.c b/xen/arch/arm/monitor.c
> index 59ce8f635f..ae1b97993f 100644
> --- a/xen/arch/arm/monitor.c
> +++ b/xen/arch/arm/monitor.c
> @@ -63,6 +63,9 @@ int monitor_smc(void)
>          .reason = VM_EVENT_REASON_PRIVILEGED_CALL
>      };
>
> +    /* Nuke the icache as the memory may get changed underneath us. */
> +    invalidate_icache();
> +
Can you explain why you put this call before the monitor trap and not 
after? From my understanding the monitoring application may change the 
memory. But by the time you modify the instruction, the instruction 
cache may have prefetched the previous instruction. So the problem is 
still there.
Furthermore, the instruction cache may not snoop the data cache. So you 
have to ensure the data written reached the memory. Otherwise you may 
read the previous instruction. Where is it done? If you expect the 
monitor app to flush the data cache, then please comment it.
Lastly, this looks like to me that all the traps will have this issue. 
So maybe this should go in monitor_traps instead?
>      return monitor_traps(current, 1, &req);
>  }
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel