Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 3 Sep 2020 20:47:16 -0700 | From | Sean Christopherson <> | Subject | Re: [PATCH v2 1/3] KVM: x86: move kvm_vcpu_gfn_to_memslot() out of try_async_pf() |
| |
On Tue, Sep 01, 2020 at 04:15:07PM +0200, Vitaly Kuznetsov wrote: > Sean Christopherson <sean.j.christopherson@intel.com> writes: > > > On Fri, Aug 07, 2020 at 04:12:30PM +0200, Vitaly Kuznetsov wrote: > >> No functional change intended. Slot flags will need to be analyzed > >> prior to try_async_pf() when KVM_MEM_PCI_HOLE is implemented. > > > > (Sorry it took me so long to reply. No, I wasn't hoping for Paolo's > magical "queued, thanks", I just tried to not read my email while on > vacation). > > > Why? Wouldn't it be just as easy, and arguably more appropriate, to add > > KVM_PFN_ERR_PCI_HOLE and update handle_abornmal_pfn() accordinaly? > > > > Yes, we can do that, but what I don't quite like here is that > try_async_pf() does much more than 'trying async PF'. In particular, it > extracts 'pfn' and this is far from being obvious. Maybe we can rename > try_async_pf() somewhat smartly (e.g. 'try_handle_pf()')? Your > suggestion will make perfect sense to me then.
Ya, try_async_pf() is a horrible name. try_handle_pf() isn't bad, but it's not technically handling the fault. Maybe try_get_pfn() with an inverted return?
if (!try_get_pfn(...)) return RET_PF_RETRY;
| ![\](/images/icornerr.gif) |