|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 3/5] xen/x86: introduce more cache maintenance operations
On Fri, 10 Oct 2014, Jan Beulich wrote:
> >>> On 08.10.14 at 15:00, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > --- a/xen/include/asm-x86/page.h
> > +++ b/xen/include/asm-x86/page.h
> > @@ -346,6 +346,10 @@ static inline uint32_t cacheattr_to_pte_flags(uint32_t
> > cacheattr)
> >
> > /* No cache maintenance required on x86 architecture. */
> > static inline void flush_page_to_ram(unsigned long mfn) {}
> > +static inline void clean_xen_dcache_va_range(const void *p, unsigned long
> > size) {}
> > +static inline void invalidate_xen_dcache_va_range(const void *p, unsigned
> > long size) {}
> > +static inline void clean_and_invalidate_xen_dcache_va_range
> > + (const void *p, unsigned long size) {}
>
> Mind explaining what purpose the "_xen" in these names serves?
It means a Xen virtual address (as opposed to a guest p2m address or a
guest virtual address), but I guess it is pretty obvious so I should
remove it?
> Also, is simply stubbing these out correct? I.e. there are caches on
> x86, and those can both be invalidated and cleaned, so why would
> you not do so here?
Good point. The problem is that to be sure that I am doing the right
thing I would need to know what kind of flushes are required with a
non-coherent device on x86, but I don't have any examples at hand.
From the amd64 manual, I would implement invalidate with CLFLUSH, clean
and invalidate with WBINVD (even though it operates on the entire cache
so it is very heavyweight) and I would have no way to implement just
"clean". Do you agree?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |