Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1806393pxu; Sun, 6 Dec 2020 07:56:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJysOUd5PKV+rD/EyLlzsWMrenOrch0YtKZzXdu4H6WsiQlShroMQPGvNU4+wCfz69vwAT1n X-Received: by 2002:a50:ed17:: with SMTP id j23mr16475689eds.218.1607270215050; Sun, 06 Dec 2020 07:56:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607270215; cv=none; d=google.com; s=arc-20160816; b=xtmb5uLTVRyoiLexpYV+Qje40XGIRIYX2QM21l47uRRYi2+lZONPA0eZaqoaj7b8r2 ud3VPyLCbypmWhb9x2MvDMkiXKIwgexet8eRkVMiXj+NL+eMhm8ZMHq8t5DUMO0nue4g 3NHyRZdyn2FCLGZW7yIECqAqWHd566NBag3lgtF0QMTqNGVfadpg/auH9Un8sCOnakuY w8X6H3nrjjtbhlqfjVpg1faQXotJ9AyTc+Q2iDT3mpSWs4j9coLWE5JAfaRBMES1M+1k j9vqm3asp0yfx5dQyIG16JDvCkFFzgNpgcvCAAaAsmf69fPnDPzIN+ggBTaadtYylvAG 7uLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=Xex8MCSyeTt5VWLM47VHPhz4NQa3nrgt1Z/HZ5B8oIc=; b=iyHK+h2BlsTV+6c3a29DiW72Ov6xgV3Pk3+9LqxuVSH+yazPzgmGQTcRB1M33PaN/A lHiybmNjCQ3/uZtwHrwnjgz26p79gntCZ9fmMZED2khvThPAGm423oLjWGR9TGyCOHXM 0ZDZeBoWVKIQBu/+rD666lEZWbdzJ+SFXhsHPrMFQDw9FUp4l2jB68OyiRaWH8AY4Byy mknEC8o/n2w4ZGKfYAs7Iq3ft3nghJCPMQSlisQvR2m8+kVQTfA82Ue00UYLcjZrNGVm wl8+DwVsIL0SYCGojvxKQ1UH7CVKhAtQoFPqhjZeaqwXSB87ebdQ6+SV3WlaGR8pnrp8 8HzQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v10si5031776eja.441.2020.12.06.07.56.30; Sun, 06 Dec 2020 07:56:55 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726762AbgLFPyj (ORCPT + 99 others); Sun, 6 Dec 2020 10:54:39 -0500 Received: from vps-vb.mhejs.net ([37.28.154.113]:34910 "EHLO vps-vb.mhejs.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726602AbgLFPyj (ORCPT ); Sun, 6 Dec 2020 10:54:39 -0500 Received: from MUA by vps-vb.mhejs.net with esmtps (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.93.0.4) (envelope-from ) id 1klwMA-0008Jv-Q9; Sun, 06 Dec 2020 16:53:50 +0100 Subject: Re: [PATCH] KVM: mmu: Fix SPTE encoding of MMIO generation upper half To: Paolo Bonzini Cc: Sean Christopherson , Joerg Roedel , Jim Mattson , Wanpeng Li , Vitaly Kuznetsov , Jonathan Corbet , linux-doc@vger.kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org References: <156700708db2a5296c5ed7a8b9ac71f1e9765c85.1607129096.git.maciej.szmigiero@oracle.com> <370db207-7216-ae26-0c33-dab61e0fdaab@redhat.com> From: "Maciej S. Szmigiero" Message-ID: Date: Sun, 6 Dec 2020 16:53:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <370db207-7216-ae26-0c33-dab61e0fdaab@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06.12.2020 11:09, Paolo Bonzini wrote: > On 05/12/20 01:48, Maciej S. Szmigiero wrote: >> From: "Maciej S. Szmigiero" >> >> Commit cae7ed3c2cb0 ("KVM: x86: Refactor the MMIO SPTE generation handling") >> cleaned up the computation of MMIO generation SPTE masks, however it >> introduced a bug how the upper part was encoded: >> SPTE bits 52-61 were supposed to contain bits 10-19 of the current >> generation number, however a missing shift encoded bits 1-10 there instead >> (mostly duplicating the lower part of the encoded generation number that >> then consisted of bits 1-9). >> >> In the meantime, the upper part was shrunk by one bit and moved by >> subsequent commits to become an upper half of the encoded generation number >> (bits 9-17 of bits 0-17 encoded in a SPTE). >> >> In addition to the above, commit 56871d444bc4 ("KVM: x86: fix overlap between SPTE_MMIO_MASK and generation") >> has changed the SPTE bit range assigned to encode the generation number and >> the total number of bits encoded but did not update them in the comment >> attached to their defines, nor in the KVM MMU doc. >> Let's do it here, too, since it is too trivial thing to warrant a separate >> commit. >> >> Fixes: cae7ed3c2cb0 ("KVM: x86: Refactor the MMIO SPTE generation handling") >> Signed-off-by: Maciej S. Szmigiero >> --- > > > Good catch.  What do you think about this alternative definition?  It computes everything from the bit ranges. > > #define MMIO_SPTE_GEN_LOW_START         3 > #define MMIO_SPTE_GEN_LOW_END           11 > > #define MMIO_SPTE_GEN_HIGH_START        PT64_SECOND_AVAIL_BITS_SHIFT > #define MMIO_SPTE_GEN_HIGH_END          62 > > #define MMIO_SPTE_GEN_LOW_MASK          GENMASK_ULL(MMIO_SPTE_GEN_LOW_END, \ > > MMIO_SPTE_GEN_LOW_START) > #define MMIO_SPTE_GEN_HIGH_MASK GENMASK_ULL(MMIO_SPTE_GEN_HIGH_END, \ > > MMIO_SPTE_GEN_HIGH_START) > > #define MMIO_SPTE_GEN_LOW_BITS          (MMIO_SPTE_GEN_LOW_END - MMIO_SPTE_GEN_LOW_START + 1) > #define MMIO_SPTE_GEN_HIGH_BITS         (MMIO_SPTE_GEN_HIGH_END - MMIO_SPTE_GEN_HIGH_START + 1) > > #define MMIO_SPTE_GEN_LOW_SHIFT         (MMIO_SPTE_GEN_LOW_START - 0) > #define MMIO_SPTE_GEN_HIGH_SHIFT        (MMIO_SPTE_GEN_HIGH_START - MMIO_SPTE_GEN_LOW_BITS) > > #define MMIO_SPTE_GEN_MASK GENMASK_ULL(MMIO_SPTE_GEN_LOW_BITS + MMIO_SPTE_GEN_HIGH_BITS - 1, 0) I like the exiting version more since it explicitly refers to start bits 0 and 9 of the encoded generation for easy cross-checking with bit ranges in the comment above these defines in spte.h. But if you prefer it to be specified as you had proposed above I will respin the patch accordingly. > Thanks, > > Paolo > Thanks, Maciej