> For what purpose?  There was once a bug which caused this to happen and
> it caused Xen to slow to a glacial pace.  We got bored of debugging HVM
> domains after several hours and the BIOS has still not loaded the
> bootloader.
>

I'm working on an experiment to do with cache-based side channels in Cloud
environments.  Part of it involves measuring the effect of flushing the
cache every time there is a VM switch.

You don't check the return value, so what happens when the allocation
> fails?  I would say that calling *alloc() is not a sensible thing to be
> doing in __context_switch() anyway, as you are sitting doing a long
> operation while in a critical section of Xen code.
>

Unfortunately, I can chalk that up to my inexperience with C programming.
 Thanks for pointing that out.

As for the sensibility of the plan, it is still in rather early stages and
not as robust as I would like it.  As I get more working I was planning on
leaving the memory buffer permanently allocated so as not to spend time
managing it in a critical section.  If you have a suggestion for a more
practical solution I'm all ears.

Furthermore, this algorithm has no guarantee to clear the L2 cache.  In
> fact is almost certainly will not.
>

This is the code that has worked in all of my prior experiments and has
been ratified by others I have worked with.  Are you sure it wouldn't work?
 While, for simplicity's sake, I have removed portions of the code designed
to prevent pre-fetching and perhaps left out something important, my
understanding of cache-coloring, however, would still imply that the data
in the cache should be dirty, or flushed after this loop terminates.

Perhaps I have misused the term "flush".  My objective is to make each
cache line dirty, or flush it to main memory.