From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 942EFC47247 for ; Tue, 5 May 2020 15:23:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6F9B420675 for ; Tue, 5 May 2020 15:23:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gXtkEw3I" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729725AbgEEPXF (ORCPT ); Tue, 5 May 2020 11:23:05 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:28571 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729250AbgEEPXF (ORCPT ); Tue, 5 May 2020 11:23:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588692183; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xGX2KJ9vX1ibQ6yn0wPSitM9s4UBDa59NfCH4/27h40=; b=gXtkEw3I16R+xNoMTBEwMi7KxUF7CQ2Sl7EsOzkNqEB9FoRFuyST02h16r4EX/Nq5a3jO9 5iP7RdUxhClnJfsJjwZQlmHa0LgiB4rgCEfLLzcJaoEgbs+gP7FkA5ve+mDi+KuJxBG5qW DMygMCp0JzWosqqfr0wnSw+4IpFGAY0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-113-CljtSOCiPW2IFU6WEmFjaw-1; Tue, 05 May 2020 11:23:01 -0400 X-MC-Unique: CljtSOCiPW2IFU6WEmFjaw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 65205800687; Tue, 5 May 2020 15:22:59 +0000 (UTC) Received: from horse.redhat.com (ovpn-116-211.rdu2.redhat.com [10.10.116.211]) by smtp.corp.redhat.com (Postfix) with ESMTP id BD8431000327; Tue, 5 May 2020 15:22:58 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 2620B222F75; Tue, 5 May 2020 11:22:58 -0400 (EDT) Date: Tue, 5 May 2020 11:22:58 -0400 From: Vivek Goyal To: Vitaly Kuznetsov Cc: x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Sean Christopherson , Wanpeng Li , Jim Mattson Subject: Re: [PATCH RFC 3/6] KVM: x86: interrupt based APF page-ready event delivery Message-ID: <20200505152258.GB7155@redhat.com> References: <20200429093634.1514902-1-vkuznets@redhat.com> <20200429093634.1514902-4-vkuznets@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200429093634.1514902-4-vkuznets@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 29, 2020 at 11:36:31AM +0200, Vitaly Kuznetsov wrote: > Concerns were expressed around APF delivery via synthetic #PF exception as > in some cases such delivery may collide with real page fault. For type 2 > (page ready) notifications we can easily switch to using an interrupt > instead. Introduce new MSR_KVM_ASYNC_PF2 mechanism. > > One notable difference between the two mechanisms is that interrupt may not > get handled immediately so whenever we would like to deliver next event > (regardless of its type) we must be sure the guest had read and cleared > previous event in the slot. > > Signed-off-by: Vitaly Kuznetsov > --- > Documentation/virt/kvm/msr.rst | 38 +++++++++++--- > arch/x86/include/asm/kvm_host.h | 5 +- > arch/x86/include/uapi/asm/kvm_para.h | 6 +++ > arch/x86/kvm/x86.c | 77 ++++++++++++++++++++++++++-- > 4 files changed, 113 insertions(+), 13 deletions(-) > > diff --git a/Documentation/virt/kvm/msr.rst b/Documentation/virt/kvm/msr.rst > index 33892036672d..7433e55f7184 100644 > --- a/Documentation/virt/kvm/msr.rst > +++ b/Documentation/virt/kvm/msr.rst > @@ -203,14 +203,21 @@ data: > the hypervisor at the time of asynchronous page fault (APF) > injection to indicate type of asynchronous page fault. Value > of 1 means that the page referred to by the page fault is not > - present. Value 2 means that the page is now available. Disabling > - interrupt inhibits APFs. Guest must not enable interrupt > - before the reason is read, or it may be overwritten by another > - APF. Since APF uses the same exception vector as regular page > - fault guest must reset the reason to 0 before it does > - something that can generate normal page fault. If during page > - fault APF reason is 0 it means that this is regular page > - fault. > + present. Value 2 means that the page is now available. > + > + 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. > + > + For #PF delivery, disabling interrupt inhibits APFs. Guest must > + not enable interrupt before the reason is read, or it may be > + overwritten by another APF. Since APF uses the same exception > + vector as regular page fault guest must reset the reason to 0 > + before it does something that can generate normal page fault. > + If during pagefault APF reason is 0 it means that this is regular > + page fault. Hi Vitaly, Again, thinking about how errors will be delivered. Will these be using same interrupt path? As you mentioned that if interrupts are disabled, APFs are blocked. That means host will fall back to synchronous fault? If yes, that means we will need a mechanism to report errors in synchronous path too. Thanks Vivek