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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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?
It seems to me that the only way to make sure that the guest is going to
be able to see the changes made by Xen is flushing the dcache.
Unless we mandate that all Xen guests are required to have caching
enabled. 


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


> In return_to_guest: This is similar to the unmap_domain_page one but
> handles writes to pages which are permanently shared by Xen and the
> guest, e.g. the shared info page or anything mapped with
> share_xen_page_with_guest etc. This one is debatable because all users
> of this are, I think, expected to get their own barriers correct since
> this these pages are typically part of some lock free datastructure
> arrangement.

same as above

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