From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
"Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>,
stable@nongnu.org
Subject: Re: [PATCH v3] KVM: mmu: Fix SPTE encoding of MMIO generation upper half
Date: Fri, 11 Dec 2020 15:54:43 -0800 [thread overview]
Message-ID: <X9QGw9vJfzCrFNzd@google.com> (raw)
In-Reply-To: <20201211234532.686593-1-pbonzini@redhat.com>
On Fri, Dec 11, 2020, Paolo Bonzini wrote:
> From: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>
>
> 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 <maciej.szmigiero@oracle.com>
> Message-Id: <156700708db2a5296c5ed7a8b9ac71f1e9765c85.1607129096.git.maciej.szmigiero@oracle.com>
> Cc: stable@nongnu.org
I assume you want stable@vger.kernel.org?
> [Reorganize macros so that everything is computed from the bit ranges. - Paolo]
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> Compared to v2 by Maciej, I chose to keep GEN_MASK's argument calculated,
Booooo. :-D
Reviewed-by: Sean Christopherson <seanjc@google.com>
> but assert on the number of bits in the low and high parts. This is
> because any change on those numbers will have to be reflected in the
> comment, and essentially we're asserting that the comment is up-to-date.
next prev parent reply other threads:[~2020-12-12 0:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-11 23:45 [PATCH v3] KVM: mmu: Fix SPTE encoding of MMIO generation upper half Paolo Bonzini
2020-12-11 23:54 ` Sean Christopherson [this message]
2020-12-12 0:11 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X9QGw9vJfzCrFNzd@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.szmigiero@oracle.com \
--cc=pbonzini@redhat.com \
--cc=stable@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.