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 8E362C43334 for ; Thu, 23 Jun 2022 19:31:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD10E8E0185; Thu, 23 Jun 2022 15:31:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D80408E0144; Thu, 23 Jun 2022 15:31:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C47F98E0185; Thu, 23 Jun 2022 15:31:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B1E338E0144 for ; Thu, 23 Jun 2022 15:31:35 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 856DB60EBB for ; Thu, 23 Jun 2022 19:31:35 +0000 (UTC) X-FDA: 79610494950.06.0332088 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf26.hostedemail.com (Postfix) with ESMTP id A16D0140013 for ; Thu, 23 Jun 2022 19:31:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656012694; 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=nmEi4t1UpiJzBwiXbayrACz8FUOD/bWJxWRST4uLWCo=; b=IfzG2W1lyiuV4RSkqryDh7sGdubF2sPMIM0q27+ET0BFoY5e3E6S3EkLzkGa/yFMTHLZn+ kKNts6p9uUor8e90Ag4FNQQ8yorFImES8VSjnPQqV02URHAAM9JElaSVkbnQqPfQy8fKmg 2Z3wP0uhw6xaXkSTQyF2/uHk4ZhFrIM= Received: from mail-io1-f70.google.com (mail-io1-f70.google.com [209.85.166.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-400-4SLVPw0NPdWp7Z2RnSETmw-1; Thu, 23 Jun 2022 15:31:33 -0400 X-MC-Unique: 4SLVPw0NPdWp7Z2RnSETmw-1 Received: by mail-io1-f70.google.com with SMTP id m3-20020a6bbc03000000b0067277968473so186522iof.19 for ; Thu, 23 Jun 2022 12:31:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nmEi4t1UpiJzBwiXbayrACz8FUOD/bWJxWRST4uLWCo=; b=Xw6/cjv3u9c/BENtQXC32IAaEFNkR0F02sA/HYLupiBKzvV5XCJNfwpv6jDQaCqu5E BEfEdv3m4sEBgb+iH1ptgMLxdS1n4Ez9oJMCgEfqbIatqNa4Qg0v/PzXUiknhh5R+n5d SmOM0T9yEyXkbfrFAnLj02y85+NyhGcVIJNCFXwazU+EkH5FPNN3fj9TocF3LkF4jbJ2 60+tZa+1vaaUfqJrfvE9MWY8XRWi8m215auduzoQ02erCba4yA4aG4aazIOS6sXJyRNl Lhq+ljpfyOBA96Z4VkjwQqhyK74IQirSh2A8nUvOZ8YJ2On1sAp6uXHZytaH9+tlAiJF ITKw== X-Gm-Message-State: AJIora8aODKDAHFou8wUGPjl1nZt1sM29GCxaMdzIl1tmQGfxxs0QfId CDNhrD8oZn6SQH7gwNTRXznHPLG4O1X6W602E4OvHZv10gO7ZxF9avvCH9hH6dquthIq/TYITcB Gn3FPi78novA= X-Received: by 2002:a6b:2c89:0:b0:669:aa1e:7790 with SMTP id s131-20020a6b2c89000000b00669aa1e7790mr5626171ios.49.1656012692236; Thu, 23 Jun 2022 12:31:32 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v539MBz3A8fODK2oWdbD7Ma53P7m9iR4VQcs8hRmUxYNEp/givO9aGTtS2tXnL4Aiqc6xjVg== X-Received: by 2002:a6b:2c89:0:b0:669:aa1e:7790 with SMTP id s131-20020a6b2c89000000b00669aa1e7790mr5626159ios.49.1656012691992; Thu, 23 Jun 2022 12:31:31 -0700 (PDT) Received: from xz-m1.local (cpec09435e3e0ee-cmc09435e3e0ec.cpe.net.cable.rogers.com. [99.241.198.116]) by smtp.gmail.com with ESMTPSA id w2-20020a92db42000000b002d91d4d8ae0sm193674ilq.20.2022.06.23.12.31.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 12:31:31 -0700 (PDT) Date: Thu, 23 Jun 2022 15:31:29 -0400 From: Peter Xu To: Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Andrew Morton , David Hildenbrand , "Dr . David Alan Gilbert" , Andrea Arcangeli , Linux MM Mailing List Subject: Re: [PATCH 4/4] kvm/x86: Allow to respond to generic signals during slow page faults Message-ID: References: <20220622213656.81546-1-peterx@redhat.com> <20220622213656.81546-5-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656012695; a=rsa-sha256; cv=none; b=Pm64u3DlT5vD+SrZAxh1NtJVMAozfUKUS2lwT+Ifmoe6pmvWWb5znmF0PYQ4lNsrCO4ysn I4AkONpVk1NeDyeZXN5Sj6E/xvoZVg1Gzfl/94gEL3h7/SKbxHLUeWRgVWC8JB1gBwrN7E BzaGuYq+8fHjucEUaS6WIwRVt+HMjnY= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IfzG2W1l; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf26.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656012695; 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=nmEi4t1UpiJzBwiXbayrACz8FUOD/bWJxWRST4uLWCo=; b=SUv090dyCePzA3b4jW9wlowz9Ir+VEoRW4daiPVEJABULGKiwPApQ9cCVOxATSrYj2nfwt XDtszCtITQ8hX2dJV163Sl8J7mjvmvZ7AZowA7h8HufSG/FyDVpdR5Zv8LejaSwLgfeClI 6kQ3dSd6/inNrGicUcA2LYN0t4ulWuc= X-Stat-Signature: ie51496oi93ybrosgsy3hrqiews1kmqw X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A16D0140013 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IfzG2W1l; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf26.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-HE-Tag: 1656012694-66756 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: Hi, Sean, On Thu, Jun 23, 2022 at 02:46:08PM +0000, Sean Christopherson wrote: > On Wed, Jun 22, 2022, Peter Xu wrote: > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > > index e92f1ab63d6a..b39acb7cb16d 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 intr before the other ones */ > > + if (unlikely(is_intr_pfn(fault->pfn))) { > > + vcpu->run->exit_reason = KVM_EXIT_INTR; > > + ++vcpu->stat.signal_exits; > > + return -EINTR; > > + } > > + > > /* The pfn is invalid, report the error! */ > > if (unlikely(is_error_pfn(fault->pfn))) > > return kvm_handle_bad_page(vcpu, fault->gfn, fault->pfn); > > @@ -4017,6 +4024,8 @@ static int kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) > > } > > } > > > > + /* Allow to respond to generic signals in slow page faults */ > > "slow" is being overloaded here. The previous call __gfn_to_pfn_memslot() will > end up in hva_to_pfn_slow(), but because of passing a non-null async it won't wait. > This code really should have a more extensive comment irrespective of the interruptible > stuff, now would be a good time to add that. Yes I agree, especially the "async" parameter along with "atomic" makes it even more confusing as you said. But isn't that also means the "slow" here is spot-on? I mean imho it's the "elsewhere" needs cleanup not this comment itself since it's really stating the fact that this is the real slow path? Or any other suggestions greatly welcomed on how I should improve this comment. > > Comments aside, isn't this series incomplete from the perspective that there are > still many flows where KVM will hang if gfn_to_pfn() gets stuck in gup? E.g. if > KVM is retrieving a page pointed at by vmcs12. Right. The thing is I'm not confident I can make it complete easily in one shot.. I mentioned some of that in cover letter or commit message of patch 1, in that I don't think all the gup call sites are okay with being interrupted by a non-fatal signal. So what I want to do is doing it step by step, at least by introducing FOLL_INTERRUPTIBLE and having one valid user of it that covers a very valid use case. I'm also pretty sure the page fault path is really the most cases that will happen with GUP, so it already helps in many ways for me when running with a patched kernel. So when the complete picture is non-trivial to achieve in one shot, I think this could be one option we go for. With the facility (and example code on x86 slow page fault) ready, hopefully we could start to convert many other call sites to be signal-aware, outside page faults, or even outside x86, because it's really a more generic problem, which I fully agree. Does it sound reasonable to you? Thanks, -- Peter Xu