From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Pierre-eric.Pelloux-prayer@amd.com,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
dri-devel@lists.freedesktop.org, npiggin@gmail.com,
"David Stevens" <stevensd@chromium.org>
Subject: Re: [PATCH] drm/ttm: set TTM allocated pages as reserved
Date: Wed, 29 Mar 2023 10:22:22 -0700 [thread overview]
Message-ID: <ZCRzzi7bmDyOra4X@google.com> (raw)
In-Reply-To: <4a60cf2a-193f-c06c-5747-766bca1ca01f@redhat.com>
+David
On Wed, Mar 29, 2023, Paolo Bonzini wrote:
> On 3/29/23 18:43, Christian K�nig wrote:
> > >
> > >
> > > 3) other uses of kmap() must switch to MMU-notifier protection.
> >
> > I would rather suggest to return the page additionally to the pfn from
> > hva_to_pfn() when the function was able to grab a reference to it.
> >
> > When the page is then not available you can't call kmap() on that either.
> >
> > >
> > > If the DRM people are okay with SetPageReserved() as a temporary
> > > hack, we can change or remove the WARN in kvm_is_zone_device_page(),
> > > since that is what you are referring to in the commit message.
> >
> > Adding Daniel for additional comments on this, but essentially we have
> > changed quite some infrastructure to make sure that everybody uses
> > VM_PFNMAP to prevent stuff like this from happening.
> >
> > I would really prefer a proper solution in KVM instead.
>
> Hmm... Now that I think about it that would be
>
> https://lore.kernel.org/kvm/Yc4H+dGfK83BaGpC@google.com/t/
>
> Time to resurrect that work.
Ya. I had previously asked David to first eliminated the usage that isn't
protected by mmu_notifiers, but after seeing the resulting complexity, I had a
change of heart[2]. Can you weigh in on the latter thread, specifically my
proposal of using a module param to let the admin opt-in to "unsafe" kmap usage.
[1] https://lore.kernel.org/kvm/Ydhq5aHW+JFo15UF@google.com
[2] https://lore.kernel.org/all/ZBEEQtmtNPaEqU1i@google.com/
next prev parent reply other threads:[~2023-03-29 17:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-29 13:54 [PATCH] drm/ttm: set TTM allocated pages as reserved Christian König
2023-03-29 14:28 ` Paolo Bonzini
2023-03-29 15:08 ` Paolo Bonzini
2023-03-29 15:29 ` Christian König
2023-03-29 15:51 ` Paolo Bonzini
2023-03-29 16:43 ` Christian König
2023-03-29 16:56 ` Paolo Bonzini
2023-03-29 17:22 ` Sean Christopherson [this message]
2023-03-29 17:31 ` Christian König
2023-03-29 17:39 ` Sean Christopherson
2023-03-29 17:43 ` Christian König
2023-03-29 18:40 ` Sean Christopherson
2023-03-30 9:41 ` 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=ZCRzzi7bmDyOra4X@google.com \
--to=seanjc@google.com \
--cc=Pierre-eric.Pelloux-prayer@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=npiggin@gmail.com \
--cc=pbonzini@redhat.com \
--cc=stevensd@chromium.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.