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. > (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? > > You probably want to clear the icache on vcpu (re-)init rather > than reset, though (no guarantee that userspace is going to > handle system resets via PSCI). > Yes, good point. -Christoffer -- 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
