On 11 January 2015 at 17:58, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: > On Sun, Jan 11, 2015 at 05:37:52PM +0000, Peter Maydell wrote: >> On 11 January 2015 at 12:33, Christoffer Dall >> <christoffer.dall@xxxxxxxxxx> wrote: >> > On Fri, Jan 09, 2015 at 03:28:58PM +0000, Peter Maydell wrote: >> >> But implementations are allowed to hit in the cache even >> >> when the cache is disabled. In particular, setting the guest >> > >> > But how can it hit anything when the icache for the used VMID is >> > guaranteed to be clear (maybe that requires another full icache >> > invalidate for that VMID for PSCI reset)? >> >> The point is that at the moment we don't do anything to >> guarantee that we've cleared the icache. > > that's not entirely accurate, I assume all of the icache is > invalidated/cleaned at system bring-up time, and every time we re-use a > VMID (when we start a VMID rollover) we invalidate the entire icache. Right, but that doesn't catch the VM reset case, which is the one we're talking about. >> (Plus could there be >> stale data in the icache for this physical CPU for this VMID >> because we've run some other vCPU on it? Or does the process >> of rescheduling vCPUs across pCPUs and guest ASID management >> deal with that?) > > we don't clear the icache for vCPUs migrating onto other pCPUs but > invalidating the icache on a page fault won't guarantee that either. Do > we really need to do that? I don't think we do, but I haven't thought through exactly why we don't yet :-) -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
