From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: kvm-ia64@vger.kernel.org
Subject: RE: switching from KVM guest to the host .... TLBs not present?
Date: Thu, 16 Apr 2009 09:57:47 +0000 [thread overview]
Message-ID: <706158FABBBA044BAD4FE898A02E4BC2328721B9@pdsmsx503.ccr.corp.intel.com> (raw)
In-Reply-To: <49DE0856.8010700@sgi.com>
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@intel.com>
>>
>> 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
prev parent reply other threads:[~2009-04-16 9:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-09 14:38 switching from KVM guest to the host .... TLBs not present? Jes Sorensen
2009-04-10 12:47 ` Zhang, Xiantao
2009-04-11 16:04 ` Avi Kivity
2009-04-14 11:43 ` Jes Sorensen
2009-04-16 8:43 ` Jes Sorensen
2009-04-16 8:59 ` Avi Kivity
2009-04-16 9:41 ` Zhang, Xiantao
2009-04-16 9:55 ` Avi Kivity
2009-04-16 9:57 ` Zhang, Xiantao [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=706158FABBBA044BAD4FE898A02E4BC2328721B9@pdsmsx503.ccr.corp.intel.com \
--to=xiantao.zhang@intel.com \
--cc=kvm-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).