Re: [PATCH] ARM: cache coherence problem in guestcopy.c

[Tim Deegan <tim@xen.org>]

At 12:55 +0100 on 20 Jun (1371732938), Stefano Stabellini wrote:
> On Tue, 18 Jun 2013, Ian Campbell wrote:
> > On Tue, 2013-06-18 at 12:05 +0000, Jaeyong Yoo wrote:
> > > > We were also speculating that we probably want some DMBs in
> > > > context_switch_{from,to} as well as at return_to_guest.
> > > 
> > > Actually, I just learned ReOrder Buffer, and it looks like so.
> > 
> > Right. Tim and I were speculating about where and why the barriers were
> > needed:
> > 
> > In unmap_domain_page: This ensures any writes to domain memory via the
> > Xen mapping are seen by subsequent accesses via the guest mapping.
> > Likewise map_domain_page needs one to ensure that previous accesses via
> > the guest mapping will be observed (this is the issue you observed).
> 
> What if the guest doesn't have caching enabled?

Erk!  I think we can mandate that the guest use caching for memory it
shares with the hypervisor (i.e. hypercall args & responses, shared
pages, granted pages).  Otherwise we end up flushing the dcache before
and after every copy.

In any case, this is something that should get documented. :)

> > In context_switch_from: To ensure any writes done on a VCPU are seen
> > before it is rescheduled, potentially on another PCPU. It seems likely
> > that you'd want one in context_switch_to for the complementary reasons,
> 
> Is the cache shared across multiple pcpus? Because if it isn't then we
> need to flush the dcache in this case.

AIUI this is what marking accesses 'shareable' is for: to tell the caches
to keep them coherent.  If not, we're equally in trouble for all Xen's
internal data structures.

Tim.