ept identity pagetable and apic access page in kvm are pinned in memory.
As a result, they cannot be migrated/hot-removed.
But actually they don't need to be pinned in memory.
[For ept identity page]
Just do not pin it. When it is migrated, guest will be able to find the
new page in the next ept violation.
[For apic access page]
The hpa of apic access page is stored in VMCS APIC_ACCESS_ADDR pointer.
When apic access page is migrated, we update VMCS APIC_ACCESS_ADDR pointer
for each vcpu in addition.
NOTE: Tested with -cpu xxx,-x2apic option.
But since nested vm pins some other pages in memory, if user uses nested
vm, memory hot-remove will not work.
Change log v5 -> v6:
1. Patch 1/6 has been applied by Paolo Bonzini <pbonzini@xxxxxxxxxx>, just resend it.
2. Simplify comment in alloc_identity_pagetable() and add a BUG_ON() in patch 2/6.
3. Move err initialization forward in patch 3/6.
4. Rename vcpu_reload_apic_access_page() to kvm_vcpu_reload_apic_access_page() and
use it instead of kvm_reload_apic_access_page() in nested_vmx_vmexit() in patch 5/6.
5. Reuse kvm_vcpu_reload_apic_access_page() in prepare_vmcs02() and vmx_vcpu_reset() in patch 6/6.
6. Remove original patch 7 since we are not able to handle the situation in nested vm.
Tang Chen (6):
kvm: Use APIC_DEFAULT_PHYS_BASE macro as the apic access page address.
kvm: Remove ept_identity_pagetable from struct kvm_arch.
kvm: Make init_rmode_identity_map() return 0 on success.
kvm, mem-hotplug: Reload L1' apic access page on migration in
vcpu_enter_guest().
kvm, mem-hotplug: Reload L1's apic access page on migration when L2 is
running.
kvm, mem-hotplug: Unpin and remove kvm_arch->apic_access_page.
arch/x86/include/asm/kvm_host.h | 5 ++-
arch/x86/kvm/svm.c | 9 +++-
arch/x86/kvm/vmx.c | 95 +++++++++++++++++++++++------------------
arch/x86/kvm/x86.c | 25 +++++++++--
include/linux/kvm_host.h | 2 +
virt/kvm/kvm_main.c | 12 ++++++
6 files changed, 99 insertions(+), 49 deletions(-)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
