On 2014-07-14 16:58, Gleb Natapov wrote:
>>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>>> index ffbe557..7080eda 100644
>>>> --- a/arch/x86/kvm/x86.c
>>>> +++ b/arch/x86/kvm/x86.c
>>>> @@ -5929,6 +5929,18 @@ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
>>>> kvm_apic_update_tmr(vcpu, tmr);
>>>> }
>>>>
>>>> +static void vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
>>>> +{
>>>> + /*
>>>> + * When the page is being migrated, GUP will wait till the migrate
>>>> + * entry is replaced with the new pte entry pointing to the new page.
>>>> + */
>>>> + struct page *page = gfn_to_page_no_pin(vcpu->kvm,
>>>> + APIC_DEFAULT_PHYS_BASE>> PAGE_SHIFT);
>>> If you do not use kvm->arch.apic_access_page to get current address why not
>>> drop it entirely?
>>>
>>
>> I should also update kvm->arch.apic_access_page here. It is used in other
>> places
>> in kvm, so I don't think we should drop it. Will update the patch.
> What other places? The only other place I see is in nested kvm code and you
> can call
> gfn_to_page_no_pin() there instead of using kvm->arch.apic_access_page
> directly. But
> as far as I see nested kvm code cannot handle change of APIC_ACCESS_ADDR phys
> address.
> If APIC_ACCESS_ADDR changes during nested guest run, non nested vmcs will
> still have old
> physical address. One way to fix that is to set KVM_REQ_APIC_PAGE_RELOAD
> during nested exit.I cannot follow your concerns yet. Specifically, how should APIC_ACCESS_ADDR (the VMCS field, right?) change while L2 is running? We currently pin/unpin on L1->L2/L2->L1, respectively. Or what do you mean? Jan
signature.asc
Description: OpenPGP digital signature
