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?
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
