Jes Sorensen wrote: > Avi Kivity wrote: >> Applied, but I note that entering the guest with any lock held is >> problematic, as the guest may spend an arbitrary amount of time in >> guest mode. Really, entering the guest is almost exactly like >> exiting to userspace. > > Hi Avi, > > I had a look at this and reworked the locking some, so we don't hold > the slots_lock when entering the guest. > > How does this look? Xiantao any thoughts of whether it's unsafe to > call kvm_vcpu_post_transition without holding that semaphore? I > believe it should be fine. > > I am still seeing issues where the host can get a lock timeout when > running large guests, but the situation seems to be better with this > patch applied. I remembered this lock should be used to avoid guest memory mappings' changes once vcpu in guest mode before. Since ia64's memory virtualization locates in VMM, so have to take the lock in VMM, otherwise, guest may access memory with old mapping, but this machanism should be ineffective after optimizing guest's TLB flush in kvm_vcpu_pre_transition. So this lock shouldn't be held noe. This patch looks fine! Thanks Jes! Acked-by : Xiantao Zhang<xiantao.zhang@xxxxxxxxx> But anyway, we should implement kvm_arch_flush_shadow to prevent guest using old mapping to access memory, otherwise guest may have issues even probably crash host once guest memory mapping changes frequently. Xiantao -- To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
