All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Gleb Natapov <gleb@kernel.org>
Cc: <mtosatti@redhat.com>, <kvm@vger.kernel.org>,
	<laijs@cn.fujitsu.com>, <isimatu.yasuaki@jp.fujitsu.com>,
	<guz.fnst@cn.fujitsu.com>, <linux-kernel@vger.kernel.org>,
	Tang Chen <tangchen@cn.fujitsu.com>
Subject: Re: [PATCH 4/4] kvm, mem-hotplug: Update apic access page when it is migrated.
Date: Mon, 7 Jul 2014 14:17:25 +0800	[thread overview]
Message-ID: <53BA3B75.3090801@cn.fujitsu.com> (raw)
In-Reply-To: <20140704101310.GE4399@minantech.com>

Hi Gleb,

Thanks for all the advices. Please see below.

On 07/04/2014 06:13 PM, Gleb Natapov wrote:
......
>>>> +static void vmx_set_apic_access_page_addr(struct kvm *kvm, hpa_t hpa)
>>>> +{
>>>> +	if (vm_need_virtualize_apic_accesses(kvm))
>>> This shouldn't even been called if apic access page is not supported. Nor
>>> mmu_notifier path neither tdp_page_fault path should ever see 0xfee00000
>>> address. BUG() is more appropriate here.
>>>
>>
>> I don't quite understand. Why calling this function here will leed to bug ?
>> (Sorry, I'm not quite understand the internal of KVM. Please help.)
> I didn't say that calling this function here will lead to a bug. I am saying that
> if vm_need_virtualize_apic_accesses() is false this function should not be called
> at all, so this check is redundant.
>

Do you mean when vm_need_virtualize_apic_accesses() is false, it should 
not be called ?
It has to be true ?

......
>>>> +	if (kvm->arch.apic_access_page_migrated) {
>>>> +		if (kvm->arch.apic_access_page)
>>>> +			kvm->arch.apic_access_page = pfn_to_page(0);
>>> All vcpus will access apic_access_page without locking here. May be
>>> set kvm->arch.apic_access_page to zero in mmu_notifier and here call
>>>   kvm_x86_ops->set_apic_access_page_addr(kvm, kvm->arch.apic_access_page);
>>>
>>
>> I'm a little confused. apic access page's phys_addr is stored in vmcs, and
>> I think it will be used by vcpu directly to access the physical page.
>> Setting kvm->arch.apic_access_page to zero will not stop it, right ?
>>
> Right, kvm->arch.apic_access_page is just a shadow value for whatever is written
> in vmcs. After setting it all vcpus need to update their vmcs values.
>
>> I'm wondering what happens when apic page is migrated, but the vmcs is still
>> holding its old phys_addr before the vcpu request is handled.
>>
> apic page should not be migrated untill all vpus are forced out of a guest mode and
> instructed to reload new value on a next guest entry. That's what we are trying to
> achieve here.
>

So, setting VMCS APIC_ACCESS_ADDR pointer to zero will not stop vcpu to 
access
apic access page, right ?

If so, all the vcpus have to stop till apic page finishes its migration, 
and new
value is set in each vcpu, which means we should stop guest, right ?

Thanks.

  reply	other threads:[~2014-07-07  6:17 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-02  9:00 [PATCH 0/4] kvm, mem-hotplug: Do not pin ept identity pagetable and apic access page Tang Chen
2014-07-02  9:00 ` [PATCH 1/4] kvm: Add gfn_to_page_no_pin() Tang Chen
2014-07-02  9:00 ` [PATCH 2/4] kvm: Add macro VMX_APIC_ACCESS_PAGE_ADDR Tang Chen
2014-07-02 16:24   ` Gleb Natapov
2014-07-03  1:19     ` Tang Chen
2014-07-02  9:00 ` [PATCH 3/4] kvm, memory-hotplug: Update ept identity pagetable when it is migrated Tang Chen
2014-07-02 16:34   ` Gleb Natapov
2014-07-03  1:19     ` Tang Chen
2014-07-04  2:36     ` Tang Chen
2014-07-04  9:49       ` Gleb Natapov
2014-07-02  9:00 ` [PATCH 4/4] kvm, mem-hotplug: Update apic access page " Tang Chen
2014-07-03 13:55   ` Gleb Natapov
2014-07-04  2:18     ` Tang Chen
2014-07-04  2:18     ` Tang Chen
2014-07-04 10:13       ` Gleb Natapov
2014-07-07  6:17         ` Tang Chen [this message]
2014-07-07  9:52         ` Tang Chen
2014-07-07 11:42           ` Nadav Amit
2014-07-07 11:54             ` Gleb Natapov
2014-07-07 12:10               ` Nadav Amit
2014-07-07 12:15                 ` Gleb Natapov
     [not found]                   ` <1408522330-18009-1-git-send-email-namit@cs.technion.ac.il>
2014-08-20  8:44                     ` [PATCH] KVM: x86: Warn on APIC base relocation Nadav Amit
2014-07-08  1:44                 ` [PATCH 4/4] kvm, mem-hotplug: Update apic access page when it is migrated Tang Chen
2014-07-08  6:46                   ` Nadav Amit
2014-07-07 10:35   ` Wanpeng Li
2014-07-08  9:40     ` Tang Chen
2014-07-03  1:17 ` [PATCH 0/4] kvm, mem-hotplug: Do not pin ept identity pagetable and apic access page Tang Chen
2014-07-03  6:04   ` Gleb Natapov
2014-07-04  6:41     ` Tang Chen

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=53BA3B75.3090801@cn.fujitsu.com \
    --to=tangchen@cn.fujitsu.com \
    --cc=gleb@kernel.org \
    --cc=guz.fnst@cn.fujitsu.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=kvm@vger.kernel.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.