[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53C52837.4030105@web.de>
Date: Tue, 15 Jul 2014 15:10:15 +0200
From: Jan Kiszka <jan.kiszka@....de>
To: Gleb Natapov <gleb@...antech.com>,
Tang Chen <tangchen@...fujitsu.com>
CC: mtosatti@...hat.com, nadav.amit@...il.com, kvm@...r.kernel.org,
laijs@...fujitsu.com, isimatu.yasuaki@...fujitsu.com,
guz.fnst@...fujitsu.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/5] kvm, mem-hotplug: Do not pin apic access page
in memory.
On 2014-07-15 14:40, Gleb Natapov wrote:
>>
>> ......
>> 7922 if (!vmx->nested.apic_access_page)
>> 7923 exec_control &=
>> 7924 ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
>> 7925 else
>> 7926 vmcs_write64(APIC_ACCESS_ADDR,
>> 7927 page_to_phys(vmx->nested.apic_access_page));
>> 7928 } else if
>> (vm_need_virtualize_apic_accesses(vmx->vcpu.kvm)) {
>> 7929 exec_control |=
>> 7930 SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
>> 7931 vmcs_write64(APIC_ACCESS_ADDR,
>> 7932 page_to_phys(vcpu->kvm->arch.apic_access_page));
>> 7933 }
>>
>> And yes, we have the problem you said here. We can migrate the page while L2
>> vm is running.
>> So I think we should enforce L2 vm to exit to L1. Right ?
>>
> We can request APIC_ACCESS_ADDR reload during L2->L1 vmexit emulation, so
> if APIC_ACCESS_ADDR changes while L2 is running it will be reloaded for L1 too.
How should this host-managed VMCS field possibly change while L2 is running?
Jan
Download attachment "signature.asc" of type "application/pgp-signature" (264 bytes)
Powered by blists - more mailing lists