[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, 2013-06-20 at 13:19 +0100, Tim Deegan wrote:
> 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.

Yes. Worse because of the reusing/reference counting scheme used in
map_domain_page I'm not sure we can tell when we need to flush the cache
vs. discard it (because the guest has written something useful behind
the cache).

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

Yes.

> > > 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.

Right they are either snooped or shared, depending on the level and the
implementation. Either way it is fine for us I think.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.