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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id B83DAC433F5 for ; Wed, 5 Jan 2022 19:19:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2D98949DED; Wed, 5 Jan 2022 14:19:53 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUijkpANwM39; Wed, 5 Jan 2022 14:19:52 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2C81F49E18; Wed, 5 Jan 2022 14:19:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6827449DED for ; Wed, 5 Jan 2022 14:19:51 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeH9njnR5LAN for ; Wed, 5 Jan 2022 14:19:50 -0500 (EST) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 1CD4749B08 for ; Wed, 5 Jan 2022 14:19:50 -0500 (EST) Received: by mail-pg1-f170.google.com with SMTP id 8so66912pgc.10 for ; Wed, 05 Jan 2022 11:19:50 -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=XMZW0gT9TtQR8qW7yP2JLQuuqwfJSbwtx/cL7KLREDP6j6/NtwRIsz7+gWbSyiLAyW 44d4yVbA10k9Jx5ZGtKZuOM6s5vwgN/p5/mRd1YQixhZ9XGt2X4cwYEU0yilgQwfQ//u THT+VZKkzVkiDUHbfVhTniVCxLidiA0dsqAepMRgxWAvlPNY77XvH1wt/ZXoqpHCk7Ft WGM7XuPm5D/Syp+YNWrOEqT7mgrx28Ji3mMfOimA/iN2Q9m7oK6fIvrYVGij46DjjWgW YgvUo3EJts0NcTN0iOO97E2SltgeGCMZ0X4IordpU7oxe6O7QOsQeDZl+9QUe+fvyJH9 tcQw== X-Gm-Message-State: AOAM533h0CPLPKZf/etvH/y3bAvl7tKcaPmMUyYLqAVZnODBmiU2h+3p 0OQX8qSfaDBovAPPUJCWeQ37jg== 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 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-Disposition: inline In-Reply-To: Cc: Wanpeng Li , kvm@vger.kernel.org, Marc Zyngier , Joerg Roedel , linux-kernel@vger.kernel.org, Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Jim Mattson X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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 :-) _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 103E4C433EF for ; Wed, 5 Jan 2022 19:21:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=SwHdqYlhMi8mWUH7ERFMw5EZPa4SEhVoUigG5z/H8p4=; b=Xh2Jj78na/8Mas BI8/QrIF/kgWaoue+Qk5Bkv2qOYEzy2b+eicOvHhgaGxnb9kJNzO4HOL4ZE6r3Vd4pT3UJ7v49iBC fiLd9EJafWD7si/K5PZvovRqZGEVAogiFzwH5n0e3eo0oenJW4bWhD84wnTqUWM4q4QkH6qtn+OiD goz9OSORbIJgPssDUjlCdhy08X26oKg02dBe96k7xsPOe+N+dV6KQofn+MIndfGdWHRaaxnsjx2im R0JV3ozlbmaGhEnIDWI6NtxcGr6YgQd/iimvGQCKyK6ZFIkxZHGVneXWe0xqbGxXU09pF8au+ACcd uqnzkDOlIyLYG7gtBtpg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5BpB-00FgB8-M2; Wed, 05 Jan 2022 19:19:53 +0000 Received: from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5Bp8-00FgAn-5C for linux-arm-kernel@lists.infradead.org; Wed, 05 Jan 2022 19:19:51 +0000 Received: by mail-pg1-x52e.google.com with SMTP id g22so93124pgn.1 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=YQSD4VhXaaxn+k3qI68Q1k4Bj68YKxCoHTaThtMekSjkYz5tU5oZrWhqqM4Qw28CZ5 4j85wSRDCY5GIVVKJDx7lv263mmDgaxoKPk/v5xABcATDsxXGWYLkc/4FYdwknPmv9xa i1dQUBkshHeDRR/UK2mf7THsA+oMXJqQAg/oJuh+OO/8BIkJwpRoEGSL0VTt67muu+eC w4KUPbIz6oFc9nuiFbIn3I1euK3i4fMK9azvirVKK1/+Y70ADT82S+bc+E3wHbCf6uQV 5S8+jSFpcfTXq6TH4+kpuoKNF70m9Btm+1VluToQpYc5LSEJxRdz3ou+qBDqqyHH68Kx NaEA== X-Gm-Message-State: AOAM530nb+Lc/xOz84XxpKRP8zY4tcbGaMdwvQ6cWHlOzpM4FPcfhUww Fvbtyv24x1mAAc/xCEBxIWvQbg== 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220105_111950_242055_1E1D52F1 X-CRM114-Status: GOOD ( 13.17 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 :-) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 5ACB1C433EF for ; Wed, 5 Jan 2022 19:20:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243458AbiAETUC (ORCPT ); Wed, 5 Jan 2022 14:20:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243499AbiAETTu (ORCPT ); Wed, 5 Jan 2022 14:19:50 -0500 Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B2571C061245 for ; Wed, 5 Jan 2022 11:19:49 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id q3so230105pfs.7 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=fJPVy5gs6opbqe9HFC32QZepERkPPhcvrbYVNg8xCrarnG314xhzRRXFcIFDEu7/Kk jNKfiTmCXChOOQ+8sI07PQzgf5rNPn2ozUuK3zeJDTq/RSniT8i/8zm0F26rb7+DXTSh dF7aajX8FcvNJCpvfbcKqTtJYNmkuVTKIJbBz9T9vI0xAHSYmIafaqjA7YK49S6dcl04 MXyD8secZrJXt0if0q6lEkgUXSI5LtUBl7hAoCJ2tGe7rnYA0S7YZjK+DkHLmqQjB3Wc HubHp7u3rzpmj7HJPrEEGGoXnbFusKq/Jp6vPCDauqf3Fkxzd1J9KJ4wZRpY+x+qum6l 0TmQ== X-Gm-Message-State: AOAM532gATWB5Ew3yCC+4Yg+Nm5u2HwldcmsaLMxj5zUxjd8zn8S1fz7 jc7E2Ikpj7KuqvSNyS/5if6CzQ== 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: kvm@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 :-)