Avi Kivity wrote: > Zhang, Xiantao wrote: >> 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. >> >> > > Shouldn't we implement kvm_arch_flush_shadow() before we apply this? It should be another issue. Even holding the lock in guest mode, it still have issue. Okay, anyway I will work out a patch to fix it. 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
