Re: [Xen-devel] [PATCH v2 3/4] xen/arm: clean and invalidate all guest caches by VMID after domain build.

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("[PATCH v2 3/4] xen/arm: clean and invalidate all guest 
caches by VMID after domain build."):
> Guests are initially started with caches disabled and so we need to make sure
> they see consistent data in RAM (requiring a cache clean) but also that they
> do not have old stale data suddenly appear in the caches when they enable
> their caches (requiring the invalidate).
> 
> This can be split into two halves. First we must flush each page as it is
> allocated to the guest. It is not sufficient to do the flush at scrub time
> since this will miss pages which are ballooned out by the guest (where the
> guest must scrub if it cares about not leaking the pagecontent). We need to
> clean as well as invalidate to make sure that any scrubbing which has occured
> gets committed to real RAM. To achieve this add a new cacheflush_page 
> function,
> which is a stub on x86.

> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index 77a4e64..306b414 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -603,6 +603,9 @@ void xc_dom_unmap_one(struct xc_dom_image *dom, xen_pfn_t 
> pfn)
>          prev->next = phys->next;
>      else
>          dom->phys_pages = phys->next;
> +
> +    xc_domain_cacheflush(dom->xch, dom->guest_domid,
> +                         phys->first, phys->first + phys->count);
>  }

The approach you are taking here is that for pages explicitly mapped
by some libxc caller, you do the flush on unmap.  But what about
callers who don't unmap ?  Are there callers which don't unmap and
which instead are relying on memory coherency assumptions which aren't
true on arm ?

Aside from this question, the code in this patch looks fine to me.

Ian.

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