On Wed, Aug 14, 2013 at 9:27 PM, Marc Zyngier <maz@xxxxxxxxxxxxxxx> wrote: > On 2013-08-14 16:41, Peter Maydell wrote: >> On 14 August 2013 16:34, Marc Zyngier <maz@xxxxxxxxxxxxxxx> wrote: >>> When userspace loads the kernel into memory, the kernel is not >>> flushed >>> to RAM, and may sit in the L3 cache if the cache is big enough. You >>> end-up executing garbage... My proposed fix is to let kvmtool do the >>> flushing, as we have userspace cache management operations for this >>> exact purpose. >> >> Why does this issue only apply to the loaded kernel and not to >> the zero bytes in the rest of RAM? I know executing zeroes >> isn't a very useful thing to do but it should be a well defined >> thing. > > Good point, and not quite sure just yet. Probably we get a zeroed, > clean page? This would apply to zeroed pages too if some Guest OS expects zeroed-out portions in Guest RAM. > > Anup, can you elaborate on how your L3 cache behaves? The L3-cache is transparent to Aarch64 CPUs. It is only bypassed when caching is disabled or when accessing non-cacheable pages. Currently, we cannot disclose more details about line allocation and replacement policy because APM X-Gene specs are not released. The issue pointed out by this patch would also apply to L2-cache (i.e. L3-cache disabled) but it usually does not manifest because L2-cache is not too big (few hundred KBs) and so dirty lines don't stay for long time in L2-cache. > > Thanks, > > M. > -- > Who you jivin' with that Cosmik Debris? > _______________________________________________ > kvmarm mailing list > kvmarm@xxxxxxxxxxxxxxxxxxxxx > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm Regards, Anup _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
