Re: [Xen-devel] [PATCH v4] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 27/01/2017 20:54, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 1:41 PM, Stefano Stabellini
> <sstabellini@xxxxxxxxxx> wrote:
> > On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
> > > When the toolstack modifies memory of a running ARM VM it may happen
> > > that the underlying memory of a current vCPU PC is changed. Without
> > > flushing the icache the vCPU may continue executing stale instructions.
> > >
> > > Also expose the xc_domain_cacheflush through xenctrl.h.
> > >
> > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
> > > Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> > > ---
> > > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > > Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > Cc: Julien Grall <julien.grall@xxxxxxx>
> > >
> > > Note: patch has been verified to solve stale icache issues on the
> > >       HiKey platform.
> > Sorry to come in the discussion late, but there has been a lot of
> > traffic on this in the last two days. The patch is clear and well
> > written, thanks for that. However, I am concerned about the performance
> > impact of the icache flush.
> >
> > What stale icache issues is it trying to solve?
> The case where it is very easy to trigger a stale icache is during an
> SMC trap on multi-core boards (like the HiKey). If the monitor
> application removes the SMC from memory in the callback (through
> xc_map_foreign_range), the SMC instruction will still happen
> repeatedly afterwards until the CPU gives up and fetches the actual
> contents of the memory. The same icache issue could get triggered any
> time the user is modifying instructions in the memory of an active VM.
> But flushing the dcache would also be required any time memory is
> modified anywhere, so exposing the libxc function would be necessary
> without the icache issue anyway.
>
> Speaking of which, after reading
> https://events.linuxfoundation.org/sites/events/files/slides/slides_17.pdf,
> shouldn't the cache flush happen both before and after memory is
> modified (as shown on slide 33)?
I have CCed Mark Rutland who wrote the slides to confirm. The example 
was about doing non-coherent DMA, the device rely on the OS to do the 
cache maintenance for the DMA operation.
In our case, the tools are mapping the region cacheable, so no need to 
do the cache flush before the modifying the memory.
Although, an issue I could see is if a guest vCPU is running with cache 
disabled (other than during early boot). In that case, we have the same 
memory region mapped with different cacheability attribute. But I think 
it will be a real mess and not really helpful as PV protocol would not work.
Cheers,

--
Julien Grall

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