On Fri, Jan 09, 2015 at 11:38:19AM +0000, Marc Zyngier wrote:
[...]
> >> @@ -258,12 +272,24 @@ bool access_sctlr(struct kvm_vcpu *vcpu,
> >> const struct coproc_params *p,
> >> const struct coproc_reg *r)
> >> {
> >> + bool was_enabled = vcpu_has_cache_enabled(vcpu);
> >> + bool now_enabled;
> >> +
> >> access_vm_reg(vcpu, p, r);
> >>
> >> - if (vcpu_has_cache_enabled(vcpu)) { /* MMU+Caches enabled? */
> >> - vcpu->arch.hcr &= ~HCR_TVM;
> >> + now_enabled = vcpu_has_cache_enabled(vcpu);
> >> +
> >> + /*
> >> + * If switching the MMU+caches on, need to invalidate the caches.
> >> + * If switching it off, need to clean the caches.
> >> + * Clean + invalidate does the trick always.
> >
> > couldn't a clean here then be writing bogus to RAM on an initial boot
> > of the guest?
>
> It shouldn't. We're supposed to start a VM with a fully invalid cache
> (what's why we call coherent_cache_guest_page). And this is no different
> from what we had before, as an invalidate by set/way was upgraded to
> clean+invalidate.
>
right, that makes sense.
Thanks,
-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
