Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1255812ybj; Thu, 7 May 2020 19:21:39 -0700 (PDT) X-Google-Smtp-Source: APiQypJNJEkvutxT5EGd+RfD3PrIJtcjzAhKcnHS87wkIPuECn0ZVX5E0ldW8YVkdO3ykU2dA2gG X-Received: by 2002:aa7:d4c3:: with SMTP id t3mr290263edr.191.1588904499372; Thu, 07 May 2020 19:21:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588904499; cv=none; d=google.com; s=arc-20160816; b=bj71YQv0JJJYEjMo5vlRqgpItz668dg/NodHsbfmnKyovurSXCXuqnoYMuRZgjbKf+ Jyx6mlL5SOGdWlgdIhY5TzD5TJs1PiEKfvyE7wumkY1yu9FsC69NOjSAT3l0ZqDd+kcK kszlLOXDtgyEV/sXHnoHz6RmgqJV9xby/0GshXJ5CwnBVKnBLFXx0jZVoy6r3x2sOyV/ luYTHfCu9CCgvO0Cd4zvJdU6I172l148NKoTe7MWgaWb3PXuydMalSxebE55w9sXNCFZ 91PzzoPO9UuWiUCHM1KGyD+R3CcWKciS7aY73mvp6FB63egsttQReDW18gBEBxJAM4H4 bQpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=JLgSaSiv4yYvs1EPOLMzvQOEIO76IkdBvqeIXiY7JGM=; b=favF/9SqHYuB35ZMGZKSWfj51b3Gl1/3AQcZdYvqJFdGhHwrT3E+4M8JT4hhFGzKOR K1go9qPJbAD6lIiTUD81IGMagi1I5O1LXH2S1fisoXK1/ujbUYYl0Sp8vYsQDIE10qZ4 qIQvUTmbU2bJ9xc3MGRrKi7zRWR6jZaPrrcbrl7/0isadMqRN8MS1/amcVLoDaslcdSm 8Jq7VCwS6KHCSzvTr+G/TWO72FQSe0r1A2Ap0etoDi78YvyazETT8WstGS4bmSMnxr5E QBGhVEBXdMbVr9CxL4mMzwAi44t88pp+2JNkQ2mI/6NQ8iM69Y6vF+HjMfZfB5sS2PBg W/fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KOUWFlT9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y11si126936ejp.513.2020.05.07.19.21.16; Thu, 07 May 2020 19:21:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KOUWFlT9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726815AbgEHCTq (ORCPT + 99 others); Thu, 7 May 2020 22:19:46 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:20827 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726509AbgEHCTp (ORCPT ); Thu, 7 May 2020 22:19:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588904384; 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=JLgSaSiv4yYvs1EPOLMzvQOEIO76IkdBvqeIXiY7JGM=; b=KOUWFlT9xjBwouWRnTx01ihtTMyn43q5Yyb6WeFfFQFgswZdM2510KQuTBmQJzxrfZApHw NrJLeaqCm5vbxcX7GuKHE20dLhECt5rqP+h/TFZZD1CSYBm0WuyCHtEcfTHiBn2YrCVA43 kjYMNq78aS3T485ZTc2I6Y4VaEa9i5U= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-476-iYG7U1iIMxian9LI29XpNQ-1; Thu, 07 May 2020 22:19:42 -0400 X-MC-Unique: iYG7U1iIMxian9LI29XpNQ-1 Received: by mail-qk1-f198.google.com with SMTP id h1so403182qkl.6 for ; Thu, 07 May 2020 19:19:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=JLgSaSiv4yYvs1EPOLMzvQOEIO76IkdBvqeIXiY7JGM=; b=MS6k/6K31VfeY2VXSk2ESI0dGMGNp0qL2XdKIZDVLzYYWmcsm+fVapoI4a371MOFKK +WsIIXg2U1H5gyGJuQRS1h70P/MAGk1SRN03jbuFZQJm28gad68JQ4HTPZt+DJl5Wigp f9Ghl+YLh3jaVEQxmVAfpKzLDEFMKH2dXSTZTUqC3hhVL2l33EWdxJvPucUbAOg+chM4 cpOihJ1ysQvkWpUXKhi3WYWf8AtOx4LfIRylNbGjI/F0CsRYYE7eiBVnbijeD1CPQDsy 25L2ucE09Tc8CtX1fFaJqfbdo9mXgx+gu/6/ij+cKL7w7rHGU0wcyScTStHu2RV05ja/ qvGA== X-Gm-Message-State: AGi0Pua/dkzqJZpkf4KdZc7JDGMfP3nNgspcpRbNm04+b/VMCap5KXH8 pDDJZqBbrXy3JttTcNGeA93PjXCnbVIYeypu1S/mgAbXet//9AD4TAw4bbY2drDrttTC6AyObDc s6Ogp+USbrhzCYPi7oA56QFEC X-Received: by 2002:a37:b244:: with SMTP id b65mr495695qkf.329.1588904381905; Thu, 07 May 2020 19:19:41 -0700 (PDT) X-Received: by 2002:a37:b244:: with SMTP id b65mr495685qkf.329.1588904381668; Thu, 07 May 2020 19:19:41 -0700 (PDT) Received: from xz-x1 ([2607:9880:19c0:32::2]) by smtp.gmail.com with ESMTPSA id i59sm333207qtb.58.2020.05.07.19.19.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 May 2020 19:19:41 -0700 (PDT) Date: Thu, 7 May 2020 22:19:39 -0400 From: Peter Xu To: Jason Gunthorpe Cc: Alex Williamson , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, cohuck@redhat.com Subject: Re: [PATCH v2 1/3] vfio/type1: Support faulting PFNMAP vmas Message-ID: <20200508021939.GT228260@xz-x1> References: <158871401328.15589.17598154478222071285.stgit@gimli.home> <158871568480.15589.17339878308143043906.stgit@gimli.home> <20200507212443.GO228260@xz-x1> <20200507235421.GK26002@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200507235421.GK26002@ziepe.ca> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 07, 2020 at 08:54:21PM -0300, Jason Gunthorpe wrote: > On Thu, May 07, 2020 at 05:24:43PM -0400, Peter Xu wrote: > > On Tue, May 05, 2020 at 03:54:44PM -0600, Alex Williamson wrote: > > > With conversion to follow_pfn(), DMA mapping a PFNMAP range depends on > > > the range being faulted into the vma. Add support to manually provide > > > that, in the same way as done on KVM with hva_to_pfn_remapped(). > > > > > > Signed-off-by: Alex Williamson > > > drivers/vfio/vfio_iommu_type1.c | 36 +++++++++++++++++++++++++++++++++--- > > > 1 file changed, 33 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c > > > index cc1d64765ce7..4a4cb7cd86b2 100644 > > > +++ b/drivers/vfio/vfio_iommu_type1.c > > > @@ -317,6 +317,32 @@ static int put_pfn(unsigned long pfn, int prot) > > > return 0; > > > } > > > > > > +static int follow_fault_pfn(struct vm_area_struct *vma, struct mm_struct *mm, > > > + unsigned long vaddr, unsigned long *pfn, > > > + bool write_fault) > > > +{ > > > + int ret; > > > + > > > + ret = follow_pfn(vma, vaddr, pfn); > > > + if (ret) { > > > + bool unlocked = false; > > > + > > > + ret = fixup_user_fault(NULL, mm, vaddr, > > > + FAULT_FLAG_REMOTE | > > > + (write_fault ? FAULT_FLAG_WRITE : 0), > > > + &unlocked); > > > + if (unlocked) > > > + return -EAGAIN; > > > > Hi, Alex, > > > > IIUC this retry is not needed too because fixup_user_fault() will guarantee the > > fault-in is done correctly with the valid PTE as long as ret==0, even if > > unlocked==true. > > It is true, and today it is fine, but be careful when reworking this > to use notifiers as unlocked also means things like the vma pointer > are invalidated. Oh right, thanks for noticing that. Then we should probably still keep the retry logic... because otherwise the latter follow_pfn() could be referencing an invalid vma already... Thanks, -- Peter Xu