From: Sean Christopherson <seanjc@google.com>
To: David Stevens <stevensd@chromium.org>
Cc: Marc Zyngier <maz@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
James Morse <james.morse@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Will Deacon <will@kernel.org>, Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
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
Date: Wed, 5 Jan 2022 19:19:45 +0000 [thread overview]
Message-ID: <YdXvUaBUvaRPsv6m@google.com> (raw)
In-Reply-To: <YdXrURHO/R82puD4@google.com>
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 :-)
next prev parent reply other threads:[~2022-01-05 19:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-29 3:43 [PATCH v5 0/4] KVM: allow mapping non-refcounted pages David Stevens
2021-11-29 3:43 ` [PATCH v5 1/4] KVM: mmu: introduce new gfn_to_pfn_page functions David Stevens
2021-12-30 19:26 ` Sean Christopherson
2021-11-29 3:43 ` [PATCH v5 2/4] KVM: x86/mmu: use gfn_to_pfn_page David Stevens
2021-12-30 19:30 ` Sean Christopherson
2021-11-29 3:43 ` [PATCH v5 3/4] KVM: arm64/mmu: " David Stevens
2021-12-30 19:45 ` Sean Christopherson
2021-11-29 3:43 ` [PATCH v5 4/4] KVM: mmu: remove over-aggressive warnings David Stevens
2021-12-30 19:22 ` Sean Christopherson
2022-01-05 7:14 ` David Stevens
2022-01-05 19:02 ` Sean Christopherson
2022-01-05 19:19 ` Sean Christopherson [this message]
2022-01-06 2:42 ` David Stevens
2022-01-06 17:38 ` Sean Christopherson
2022-01-07 2:21 ` David Stevens
2022-01-07 16:31 ` Sean Christopherson
2022-01-07 16:46 ` Sean Christopherson
2022-01-10 23:47 ` David Stevens
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=YdXvUaBUvaRPsv6m@google.com \
--to=seanjc@google.com \
--cc=alexandru.elisei@arm.com \
--cc=james.morse@arm.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=pbonzini@redhat.com \
--cc=stevensd@chromium.org \
--cc=suzuki.poulose@arm.com \
--cc=wanpengli@tencent.com \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).