Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752208AbdF1OUz (ORCPT ); Wed, 28 Jun 2017 10:20:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36362 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752087AbdF1OUo (ORCPT ); Wed, 28 Jun 2017 10:20:44 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D6B3780082 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=pbonzini@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D6B3780082 Subject: Re: [PATCH v6 3/4] KVM: async_pf: Force a nested vmexit if the injected #PF is async_pf To: Wanpeng Li Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , "linux-kernel@vger.kernel.org" , kvm , Wanpeng Li References: <1498652712-10283-1-git-send-email-wanpeng.li@hotmail.com> <1498652712-10283-4-git-send-email-wanpeng.li@hotmail.com> <293c4524-5869-2d3f-e0a3-92bde4430b81@redhat.com> <20170628133852.GA3261@potion> <810b3613-72e8-4f34-2757-e622f922ae03@redhat.com> From: Paolo Bonzini Message-ID: <92bdfd0d-f208-eeea-4d03-0dfddd467338@redhat.com> Date: Wed, 28 Jun 2017 16:20:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 28 Jun 2017 14:20:44 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 674 Lines: 19 On 28/06/2017 16:17, Wanpeng Li wrote: >> If for now we can leave out the GET/SET_VCPU_EVENTS changes, that would >> be best. nested_apf and nested_apf_token should be migrated together >> with the rest of the nested virt state. > Radim explains why we at least needs nested_apf here: > >> nested_apf is not #PF: if we didn't pass nested_apf, then the exception would be injected as #PF to L2 after migration. Yes, but migration of a L1 hypervisor is broken anyway. > Do you mean we can ignore it here and depends on Jim's patches to > completely handle it? Ignore it here, remember it when someone picks up Jim's patches, and also serialize nested_apf_token. Paolo