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

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



On Tue, 2014-02-04 at 15:32 +0000, Ian Jackson wrote:
> 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 ?

Callers which don't unmap would be leaking mappings and therefore buggy
in a long running toolstack.

Also after the initial start of day period we require that the guest
enable its caches.

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

Thanks.



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