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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23409C19F2A for ; Thu, 11 Aug 2022 20:12:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BC628E0002; Thu, 11 Aug 2022 16:12:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 16BC98E0001; Thu, 11 Aug 2022 16:12:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0331E8E0002; Thu, 11 Aug 2022 16:12:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E8AE68E0001 for ; Thu, 11 Aug 2022 16:12:43 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BCD7B1A17DB for ; Thu, 11 Aug 2022 20:12:43 +0000 (UTC) X-FDA: 79788409806.25.CAF2EF6 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by imf31.hostedemail.com (Postfix) with ESMTP id 4916920063 for ; Thu, 11 Aug 2022 20:12:43 +0000 (UTC) Received: by mail-pl1-f177.google.com with SMTP id g13so10912084plo.6 for ; Thu, 11 Aug 2022 13:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=J6XJTtC/0ZZznXds9lO5+FIfn1/ZZY6xTpOd5utreKU=; b=WTapKI2wdWL9/IeH/nDGI9PBvCMzF7oKPrrHKxKfIf/OREqtcHKiTD0YN2Er/sukD7 SRMXM8koRrze0x1MfzbbS47TcAEey9HQiA4LpdxNSrR9Ot81wTj9aj+L+4q8fp7qUWPm XF26K6/w1ppXhOR3adrhkipkqOvGE94mF2di/EGoQf0D6Y4GtMlzsBNKJCIZ1pypfa6V 9rDiJUYVcDvW8t8CbNlZ9TvQs+bw3EBcax4AJRKAMP32hbhZmT+GVGG7vFsd/HxVoVM9 h6X1mY70Dxak9fiX2chYgvfgzki8PoM4ZWLE/OCpWLPKiI/IukFx1g3xqWaaea85A291 SXtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=J6XJTtC/0ZZznXds9lO5+FIfn1/ZZY6xTpOd5utreKU=; b=Wi2XsN1SQNvHpcFPhqbf0Vke1nHS6TFpZEAu0WPRylQwr0RJYvuK60x+5WC9PYWskc xtekhsUVndN1amAz6q6XguLULJxSDCdewaVqwdH+TxNwoB7OxJcOiNJ7m1JbG2kyCGiC eh7lBV2WejV8iBcvqrtAWXr4N5oMnQheV9M/22frD/d/DK9uChj9Acldt8MHPgb4tG4r wK3bpqMMF5qkf7DyZfdqCFwFJEudtQpfHHOFY6YfzF26/49ACumW/8CDPs0V86tDeZHS 2cPHRw4GIHH1FGAN2ZdoPf7snhNtGq2Q9sd6ZaVxW4T/D7J4+vJfcXrPLvtHcgM4eUgX lK/Q== X-Gm-Message-State: ACgBeo2lVCBkSLGFYPptQIMkumH6Vc1QVaL2AZWnCvT3IhzeJSLS82Yx 9ZOZKW5mdo5A5TeZyH9HNQUeF2IDVXOb+w== X-Google-Smtp-Source: AA6agR5fvGG4iLPirmWk6yFAFl2p9rQ7RnkfVpD9XaxEXeYVv/sCb+r3A8GOKBakrsGU/A3D+/pQ+w== X-Received: by 2002:a17:90a:fe9:b0:1f5:c9c:72bf with SMTP id 96-20020a17090a0fe900b001f50c9c72bfmr10190076pjz.69.1660248762210; Thu, 11 Aug 2022 13:12:42 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id v11-20020a17090a00cb00b001f50e4c43c4sm4066347pjd.22.2022.08.11.13.12.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Aug 2022 13:12:41 -0700 (PDT) Date: Thu, 11 Aug 2022 20:12:38 +0000 From: Sean Christopherson To: Peter Xu Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, David Hildenbrand , "Dr . David Alan Gilbert" , John Hubbard , Linux MM Mailing List , Andrew Morton , Paolo Bonzini , Andrea Arcangeli Subject: Re: [PATCH v2 3/3] kvm/x86: Allow to respond to generic signals during slow page faults Message-ID: References: <20220721000318.93522-1-peterx@redhat.com> <20220721000318.93522-4-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220721000318.93522-4-peterx@redhat.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660248763; a=rsa-sha256; cv=none; b=XM3cuaZNJJDPATR3Se67zCcaqtypuKTL9W3CIDhNzbaddf7cDQf1r8Kmix2mHw+EfPasW7 T+24lObHlUF5BzCqVs4iZS90yElCPXyrclS/Z8tKo65upNlKk/ymN6WBJDvHA9V1LyXY0R UHmRgiUL/Sy/Qh+O3j7nE7bIjUS/k7A= ARC-Authentication-Results: i=1; imf31.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WTapKI2w; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf31.hostedemail.com: domain of seanjc@google.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=seanjc@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660248763; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=J6XJTtC/0ZZznXds9lO5+FIfn1/ZZY6xTpOd5utreKU=; b=Oc1Fm0WSH5dYfr9mLByxKSxQ2h+Z1IviZd869LTcVemOO47qGL2i5tCDHD6x3mK0g5Q9yW kQd42yRqPF7PmBbJeHWkRZDo6ZtC3jM05m19pLD9tsggug83iaYxgldkmC7kXZIWILAsQw Zwjmc8dUdZ6ZLTOJ80bwIhfJxLUmvYI= X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 4916920063 Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WTapKI2w; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf31.hostedemail.com: domain of seanjc@google.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=seanjc@google.com X-Stat-Signature: usjgy1gse4ofrtc7b5q3oi974md4rcpj X-Rspam-User: X-HE-Tag: 1660248763-741587 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jul 20, 2022, Peter Xu wrote: > All the facilities should be ready for this, what we need to do is to add a > new "interruptible" flag showing that we're willing to be interrupted by > common signals during the __gfn_to_pfn_memslot() request, and wire it up > with a FOLL_INTERRUPTIBLE flag that we've just introduced. > > Note that only x86 slow page fault routine will set this to true. The new > flag is by default false in non-x86 arch or on other gup paths even for > x86. It can actually be used elsewhere too but not yet covered. > > When we see the PFN fetching was interrupted, do early exit to userspace > with an KVM_EXIT_INTR exit reason. > > Signed-off-by: Peter Xu > --- > arch/arm64/kvm/mmu.c | 2 +- > arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +- > arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +- > arch/x86/kvm/mmu/mmu.c | 16 ++++++++++++-- > include/linux/kvm_host.h | 4 ++-- > virt/kvm/kvm_main.c | 30 ++++++++++++++++---------- > virt/kvm/kvm_mm.h | 4 ++-- > virt/kvm/pfncache.c | 2 +- > 8 files changed, 41 insertions(+), 21 deletions(-) I don't usually like adding code without a user, but in this case I think I'd prefer to add the @interruptible param and then activate x86's kvm_faultin_pfn() in a separate patch. It's rather difficult to tease out the functional x86 change, and that would also allow other architectures to use the interruptible support without needing to depend on the functional x86 change. And maybe squash the addition of @interruptible with the previous patch? I.e. add all of the infrastructure for KVM_PFN_ERR_SIGPENDING in patch 2, then use it in x86 in patch 3. > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 17252f39bd7c..aeafe0e9cfbf 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -3012,6 +3012,13 @@ static int kvm_handle_bad_page(struct kvm_vcpu *vcpu, gfn_t gfn, kvm_pfn_t pfn) > static int handle_abnormal_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault, > unsigned int access) > { > + /* NOTE: not all error pfn is fatal; handle sigpending pfn first */ > + if (unlikely(is_sigpending_pfn(fault->pfn))) { Move this into kvm_handle_bad_page(), then there's no need for a comment to call out that this needs to come before the is_error_pfn() check. This _is_ a "bad" PFN, it just so happens that userspace might be able to resolve the "bad" PFN. > + vcpu->run->exit_reason = KVM_EXIT_INTR; > + ++vcpu->stat.signal_exits; > + return -EINTR; For better or worse, kvm_handle_signal_exit() exists and can be used here. I don't love that KVM details bleed into xfer_to_guest_mode_work(), but that's a future problem. I do think that the "return -EINTR" should be moved into kvm_handle_signal_exit(), partly for code reuse and partly because returning -EINTR is very much KVM ABI. Oof, but there are a _lot_ of paths that can use kvm_handle_signal_exit(), and some of them don't select KVM_XFER_TO_GUEST_WORK, i.e. kvm_handle_signal_exit() should be defined unconditionally. I'll work on a series to handle that separately, no reason to take a dependency on that cleanup. So for now, static int kvm_handle_bad_page(struct kvm_vcpu *vcpu, gfn_t gfn, kvm_pfn_t pfn) { if (pfn == KVM_PFN_ERR_SIGPENDING) { kvm_handle_signal_exit(vcpu); return -EINTR; } ... }