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 0E0C8C433FE for ; Wed, 5 Jan 2022 19:20:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243469AbiAETUD (ORCPT ); Wed, 5 Jan 2022 14:20:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243500AbiAETTu (ORCPT ); Wed, 5 Jan 2022 14:19:50 -0500 Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B57A7C061201 for ; Wed, 5 Jan 2022 11:19:49 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id r5so77249pgi.6 for ; Wed, 05 Jan 2022 11:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qoub34JKMYw80YSVF2J+hWLmoHzppRyhKwTIl4ud58A=; b=eJrm9vSQlYbjzA48SXuyQTX4vpv+0waa/m6b4+CGvv+TU/vaqalx+wW2nsSxEQ/9vt A1suumBCxyzaCyNgn32IdqREfwZqOk/nXRQaoAh5CC60NGExeXlyi31EGxNmYxTQEX4E sQifAS+vZypu+S3JY78d2kp/YnmHYIUm5hak6fwjzowpaKSAXq5lBDIqAjzDrUlgI6lA KZYptrb10ts7MYcBXTd91Zphk5IkT12dQBvNVkTmAySlUziWKC75l3HxKYPl617awyGC o8+l5yF/ne1DrgpDW61L5Cb9yCX34IVOYNXYh6PnfvMZk7x3F7tG0p/lLsdCZ42dXxXJ EFLg== 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=qoub34JKMYw80YSVF2J+hWLmoHzppRyhKwTIl4ud58A=; b=j15PTWIMecSJgidDhKszd3gfOSX5OtOh9tRMF0T+5ibKPmw+fxXumV/vKXmzUPBJMj dVN1WJllx4r1NNRYzzo42dvR4SX3xG3tQzm1im6E9sxgcTJOX2sGj/IuIztZpxRX8BOV XEBmXTKcHwmk95vR31QieOukeei1CFK4mMjmLpkxGnXUyM5mIO6pqNO05DnHnxRGhKA6 zCZBwUD7jSTgTfLuk0MaIaQ8TtEwI+qn+AQbiGV4DTiz33G0BwOO4/xsmdworzLK1r/T 3mfX2zDIY8pdYnBuoyDvh9EyZNSqDoVoQMLlEYLcPMJomWJFG6vVodXyxcZvSCPQhJeT DY4A== X-Gm-Message-State: AOAM531rSZMazJRpVKtWtAOvb3nYq6eT5sPDX4CsQbimwjOnjWwI/r5R 7hKzkM0ggoPHB/BczL9tSL+ZQw== X-Google-Smtp-Source: ABdhPJxye1sjvjOvj00utsHDdoqYNY5iCIYZuac2xNc6/XTpseq2jJOALu2rGleR4A8aeXodNqfdiQ== X-Received: by 2002:a63:1422:: with SMTP id u34mr49958790pgl.135.1641410389102; Wed, 05 Jan 2022 11:19:49 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id a17sm3400933pjs.23.2022.01.05.11.19.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jan 2022 11:19:48 -0800 (PST) Date: Wed, 5 Jan 2022 19:19:45 +0000 From: Sean Christopherson To: David Stevens Cc: Marc Zyngier , Paolo Bonzini , James Morse , Alexandru Elisei , Suzuki K Poulose , Will Deacon , Wanpeng Li , Jim Mattson , Joerg Roedel , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v5 4/4] KVM: mmu: remove over-aggressive warnings Message-ID: References: <20211129034317.2964790-1-stevensd@google.com> <20211129034317.2964790-5-stevensd@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 05, 2022, Sean Christopherson wrote: > Ah, I got royally confused by ensure_pfn_ref()'s comment > > * Certain IO or PFNMAP mappings can be backed with valid > * struct pages, but be allocated without refcounting e.g., > * tail pages of non-compound higher order allocations, which > * would then underflow the refcount when the caller does the > * required put_page. Don't allow those pages here. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > that doesn't apply here because kvm_faultin_pfn() uses the low level > __gfn_to_pfn_page_memslot(). On fifth thought, I think this is wrong and doomed to fail. By mapping these pages into the guest, KVM is effectively saying it supports these pages. But if the guest uses the corresponding gfns for an action that requires KVM to access the page, e.g. via kvm_vcpu_map(), ensure_pfn_ref() will reject the access and all sorts of bad things will happen to the guest. So, why not fully reject these types of pages? If someone is relying on KVM to support these types of pages, then we'll fail fast and get a bug report letting us know we need to properly support these types of pages. And if not, then we reduce KVM's complexity and I get to keep my precious WARN :-)