Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752582AbdFQBlm (ORCPT ); Fri, 16 Jun 2017 21:41:42 -0400 Received: from mail-ot0-f196.google.com ([74.125.82.196]:33513 "EHLO mail-ot0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752441AbdFQBlk (ORCPT ); Fri, 16 Jun 2017 21:41:40 -0400 MIME-Version: 1.0 In-Reply-To: <20170616153832.GA5980@potion> References: <1497493615-18512-1-git-send-email-wanpeng.li@hotmail.com> <1497493615-18512-4-git-send-email-wanpeng.li@hotmail.com> <20170616133702.GA6360@potion> <20170616153832.GA5980@potion> From: Wanpeng Li Date: Sat, 17 Jun 2017 09:41:39 +0800 Message-ID: Subject: Re: [PATCH v2 3/4] KVM: async_pf: Force a nested vmexit if the injected #PF is async_pf To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Cc: "linux-kernel@vger.kernel.org" , kvm , Paolo Bonzini , Wanpeng Li Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v5H1fm6Z023593 Content-Length: 2906 Lines: 62 2017-06-16 23:38 GMT+08:00 Radim Krčmář : > 2017-06-16 22:24+0800, Wanpeng Li: >> 2017-06-16 21:37 GMT+08:00 Radim Krčmář : >> > 2017-06-14 19:26-0700, Wanpeng Li: >> >> From: Wanpeng Li >> >> >> >> Add an async_page_fault field to vcpu->arch.exception to identify an async >> >> page fault, and constructs the expected vm-exit information fields. Force >> >> a nested VM exit from nested_vmx_check_exception() if the injected #PF >> >> is async page fault. >> >> >> >> Cc: Paolo Bonzini >> >> Cc: Radim Krčmář >> >> Signed-off-by: Wanpeng Li >> >> --- >> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> >> @@ -452,7 +452,11 @@ EXPORT_SYMBOL_GPL(kvm_complete_insn_gp); >> >> void kvm_inject_page_fault(struct kvm_vcpu *vcpu, struct x86_exception *fault) >> >> { >> >> ++vcpu->stat.pf_guest; >> >> - vcpu->arch.cr2 = fault->address; >> >> + vcpu->arch.exception.async_page_fault = fault->async_page_fault; >> > >> > I think we need to act as if arch.exception.async_page_fault was not >> > pending in kvm_vcpu_ioctl_x86_get_vcpu_events(). Otherwise, if we >> > migrate with pending async_page_fault exception, we'd inject it as a >> > normal #PF, which could confuse/kill the nested guest. >> > >> > And kvm_vcpu_ioctl_x86_set_vcpu_events() should clean the flag for >> > sanity as well. >> >> Do you mean we should add a field like async_page_fault to >> kvm_vcpu_events::exception, then saves arch.exception.async_page_fault >> to events->exception.async_page_fault through KVM_GET_VCPU_EVENTS and >> restores events->exception.async_page_fault to >> arch.exception.async_page_fault through KVM_SET_VCPU_EVENTS? > > No, I thought we could get away with a disgusting hack of hiding the > exception from userspace, which would work for migration, but not if > local userspace did KVM_GET_VCPU_EVENTS and KVM_SET_VCPU_EVENTS ... > > Extending the userspace interface would work, but I'd do it as a last > resort, after all conservative solutions have failed. > async_pf migration is very crude, so exposing the exception is just an > ugly workaround for the local case. Adding the flag would also require > userspace configuration of async_pf features for the guest to keep > compatibility. > > I see two options that might be simpler than adding the userspace flag: > > 1) do the nested VM exit sooner, at the place where we now queue #PF, > 2) queue the #PF later, save the async_pf in some intermediate > structure and consume it at the place where you proposed the nested > VM exit. Yeah, this hidden looks rational to me, even if we lost a PAGE_NOTREADY async_pf to L1, that just a hint to L1 reschedule optimization, and PAGE_READY async_pf will be guranteed by the wakeup all after live migration. Regards, Wanpeng Li