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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-02-06 at 14:26 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 05/02/14 16:03, Ian Campbell wrote:
> > 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.
> >
> > Secondly we need to flush anything which the domain builder touches, which 
> > we
> > do via a new domctl.
> 
> As I understand, there is no hypercall continuation so if a domain give 
> a big range Xen will get stuck for a long time (no softirq will be 
> handled on the current processor ...). Shall we at least use 
> hypercall_create_continuation?

The hypercall deliberately limits the allowable range to avoid this.

This was discussed with Jan in a previous iteration, the other places
which end up here have a similar property, perhaps as a future cleanup
they can all be made preemptable.

Ian.


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