[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <15c625c5-d551-85fd-8412-f88503e6a86b@redhat.com>
Date: Wed, 29 Apr 2020 15:21:45 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>, x86@...nel.org,
kvm@...r.kernel.org
Subject: Re: [PATCH RFC 3/6] KVM: x86: interrupt based APF page-ready event
delivery
On 29/04/20 14:40, Vitaly Kuznetsov wrote:
> Paolo Bonzini <pbonzini@...hat.com> writes:
>
>> On 29/04/20 11:36, Vitaly Kuznetsov wrote:
>>> +
>>> + Type 1 page (page missing) events are currently always delivered as
>>> + synthetic #PF exception. Type 2 (page ready) are either delivered
>>> + by #PF exception (when bit 3 of MSR_KVM_ASYNC_PF_EN is clear) or
>>> + via an APIC interrupt (when bit 3 set). APIC interrupt delivery is
>>> + controlled by MSR_KVM_ASYNC_PF2.
>>
>> I think we should (in the non-RFC version) block async page faults
>> completely and only keep APF_HALT unless the guest is using page ready
>> interrupt delivery.
>
> Sure, we can do that. This is, however, a significant behavioral change:
> APF_HALT frees the host, not the guest, so even if the combined
> performance of all guests on the same pCPU remain the same guests with
> e.g. a lot of simultaneously running processes may suffer more.
Yes, it is a significant change. However the resulting clean up in the
spec is significant, because we don't have type 2 notifications at all
anymore.
(APF_HALT does free the guest a little bit by allowing interrupt
delivery during a host page fault; in particular it lets the scheduler
tick run, which does improve responsiveness somewhat significantly).
Likewise, I think we should clean up the guest side without prejudice.
Patch 6 should disable async page fault unless page-ready interrupts are
available, and drop the page ready case from the #PF handler.
Thanks,
Paolo
> In theory, we can keep two mechanisms side by side for as long as we
> want but if the end goal is to have '#PF abuse eliminated' than we'll
> have to get rid of the legacy one some day. The day when the new
> mechanism lands is also a good choice :-)
Powered by blists - more mailing lists