DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5D10FC054C5E
Subject: Re: [PATCH v6 3/4] KVM: async_pf: Force a nested vmexit if the
 injected #PF is async_pf
To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>
Cc: Wanpeng Li <kernellwp@gmail.com>, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org, Wanpeng Li <wanpeng.li@hotmail.com>
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>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <f3a51aef-ab0a-b29f-dfa0-5490518d6fcc@redhat.com>
Date: Wed, 28 Jun 2017 15:48:38 +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: <20170628133852.GA3261@potion>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1454
Lines: 35


On 28/06/2017 15:38, Radim Krčmář wrote:
>> Radim, Wanpeng,
>>
>> the patch is nice now but I'm still not 100% sure about the live
>> migration part.  Why do we need to pass nested_apf to userspace, but not
>> nested_apf_token?
>
> We do not need it for migration, but unavailable nested_apf_token
> already breaks checkpoint & restore from userspace ... I think the
> cleanest way would be to add a new paravirtual event for nested_apf.
> (Or just keep delaying the apf.)

Indeed.  With Jim's plans to migrate nested virt data, I was wondering
if nested_apf and nested_apf_token would be better placed in that ioctl,
rather than GET/SET_VCPU_EVENTS.

Nested-virt migration is broken anyway until we have Jim's patches, so
there's little point in migrating nested_apf only.  Do you agree?

> Migration does a "async-pf-broadcast" while setting the async-pf MSR on
> destination, which resumes all async-pf waiters.
> Userspace actually has to drop the async-pf event on migration, because
> the destination has invalid nested_apf_token.  (It's a horrible design.)

Yes, this was my question essentially.  I would still migrate
nested_apf_token (as part of nested virt state), and then clear it in
KVM when doing the async-pf broadcast.

Paolo

> nested_apf is not #PF: if we didn't pass nested_apf, then the exception
> would be injected as #PF to L2 after migration.  (Local KVM could
> remember that the #PF is nested_apf and do some ugly hacks.)