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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28978C54EE9 for ; Wed, 7 Sep 2022 19:56:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229965AbiIGT4D (ORCPT ); Wed, 7 Sep 2022 15:56:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229531AbiIGTz4 (ORCPT ); Wed, 7 Sep 2022 15:55:56 -0400 Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EBB4EA61CD for ; Wed, 7 Sep 2022 12:55:53 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id q21so1841149qtp.7 for ; Wed, 07 Sep 2022 12:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=reg182tBPdMyHHqhIyhd0PReinakkrLNe0xqHZC9tHU=; b=HGsl5LOrvfdnuyNEVcB+B1VQp1UuGBIOQoUWByoYPBAOyvlWj9vIrmlIosnh0QOvjp 9t1pLdGWzfwvo7PTNeeXZpHQeCZDCMAbxR4j6DpbkpqAtHiJ1boF9wUSCWFLMrBlcaHp YoTv+kHo4THsJ/Mc63JM+YKqeESn3s2WG47rnSxevKm9v0SgRfxj/b/FSTqHN+FVbbdE YRUwQy1C4ktcAsIQk6ZxdocxEK3yR01eWqg2vLczmE6Ww5bfdd1+Dl8taxY2Tf/9XWTX 2SLCSM/ki21AbuD+egy3jf01r8hYIK/sKWh+WkDXR3hVVPW6f8vUKxGd138OM1Q+9SRg KRIw== 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:subject:date; bh=reg182tBPdMyHHqhIyhd0PReinakkrLNe0xqHZC9tHU=; b=Z7vHXhuSLU8zgocktMJf7IiAI6LM530egG8NAFS7KWlZrwzN0XnUjfTgllt7BrIB3v wyj+Xd1lCPNFjHjXT2BcKW7vKLcFkeiauFeuPU70mOfDvNTetxgukSXmTnu4i0OBqRrV cvJh6aT5v+wGGndpHc+FSi7Ojx/uKM6ebLIRZ9WGaKftqB1LIlkptxe+Kl0DPSD0HGfi s81hQEsiTDkqEYI3aFpCulmwUfcnhWoIx6grgLuGMzwdQrbRpj4jJL6Cmj3+9Qnfsro4 tcvhRmcDTR0t570xLL5azcwJo45wxg2NgWaPdrii3/AuBLk6Nt+MLLNBQmsuAp730usN 7Bzw== X-Gm-Message-State: ACgBeo0YLnZci2elQN3dzYX0s8Y86b6nmISBNjQQNWE86DBfLzK/h2Gh cjNO8yNriwPgkpCYWLkobXZfiUoZZIfh9Q== X-Google-Smtp-Source: AA6agR71wy1OO/ymcMptPhtEDcay7FQ+pBe7sqv5WOFog+U5XySjMiaLOl4gJ+FO5Lod2IyxAWvAbA== X-Received: by 2002:a05:622a:15c7:b0:344:5321:5874 with SMTP id d7-20020a05622a15c700b0034453215874mr4917567qty.506.1662580552067; Wed, 07 Sep 2022 12:55:52 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id m8-20020ac866c8000000b003445d06a622sm12968811qtp.86.2022.09.07.12.55.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Sep 2022 12:55:51 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1oW19K-008kzP-5v; Wed, 07 Sep 2022 16:55:50 -0300 Date: Wed, 7 Sep 2022 16:55:50 -0300 From: Jason Gunthorpe To: Alex Williamson Cc: David Hildenbrand , "Tian, Kevin" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "lpivarc@redhat.com" , "Liu, Jingqi" , "Lu, Baolu" Subject: Re: [PATCH] vfio/type1: Unpin zero pages Message-ID: References: <166182871735.3518559.8884121293045337358.stgit@omen> <20220907095552.336c8f34.alex.williamson@redhat.com> <20220907125627.0579e592.alex.williamson@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220907125627.0579e592.alex.williamson@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 07, 2022 at 12:56:27PM -0600, Alex Williamson wrote: > I thought we'd already agreed that we were stuck with locked_vm for > type1 and any compatibility mode of type1 due to this. Native iommufd > support can do the right thing since userspace will need to account for > various new usage models anyway. We did, that was for the iommufd situation (which will also hit the same zeropage issue, sigh) - this discussion is about fixing a bug in vfio and what many consider a bug in GUP. My point is I'm still not convinced we can really consider these limits as ABI because it opens a pandoras box of kernel limitations. > I've raised the issue with David for the zero page accounting, but I > don't know what the solution is. libvirt automatically adds a 1GB > fudge factor to the VM locked memory limits to account for things like > ROM mappings, or at least the non-zeropage backed portion of those > ROMs. I think that most management tools have adopted similar, so the > majority of users shouldn't notice. However this won't cover all > users, so we certainly risk breaking userspace if we introduce hard > page accounting of zero pages. It sounds like things will be fine. 1GB fudge is pretty big. For things like this ABI compat is not about absolute compatability in the face of any userspace, but a real-world compatibility "does something that actually exists break?" So I would be happier if we had an actual deployed thing that breaks.. I would be inclined to go with the simple fix and rely on the fudge. If someone does come with an actual break then lets do one of the work arounds. Given the whole thing is obstensibly for security it is better to keep it simple and sane then to poke it full of holes. > module parameter defined limit. We might also consider whether we > could just ignore zero page mappings, maybe with a optional "strict" > mode module option to generate an errno on such mappings. Thanks, Once GUP is fixed vfio won't see the zero pages anymore :( That really limits the choices for a work around :( Jason