From: Paolo Bonzini <pbonzini@redhat.com>
To: "Christian König" <christian.koenig@amd.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: Boris Brezillon <boris.brezillon@collabora.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Hildenbrand <david@kernel.org>,
Michal Hocko <mhocko@suse.com>, Sergio Lopez <slp@redhat.com>,
Huang Rui <ray.huang@amd.com>,
bcm-kernel-feedback-list@broadcom.com,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org
Subject: Re: [PATCH RFT 3/3] drm/ttm, drm/vmwgfx: directly create writable PTEs when mkwrite is in use
Date: Wed, 5 Aug 2026 16:48:45 +0200 [thread overview]
Message-ID: <12bd995c-e320-47c9-adb1-fff3a14bddc7@redhat.com> (raw)
In-Reply-To: <c1652ce8-0b0a-49a1-a842-bf1a5290cc1a@amd.com>
On 8/5/26 14:58, Christian König wrote:
> On 7/31/26 18:43, Paolo Bonzini wrote:
>> This ensures that fixup_user_fault() users see a writable PTE when
>> they request one. The flip side is that vmw_bo_vm_fault() now has
>> to record by hand the write fault, because .pfn_mkwrite() is not
>> invoked.
>>
>> Prefaulting works as before because only the first entry comes out
>> writable, while the following ones still end up executing
>> the .pfn_mkwrite() callback.
>
> Please split that patch for TTM/VMWGFX. The TTM part looks
> reasonable, but VMGFX is a completely different beast.
Note that the TTM change alone would break vmwgfx without the other
part. This is not obvious, and it's why I placed them together given
the TTM part is just one line of code, but if you prefer I can split
them (the TTM change can go second).
Let me know if "looks reasonable" counts as "Acked-by" for that part or not.
By the way, see also
https://lists.freedesktop.org/archives/dri-devel/2026-August/586696.html
- it touches the same code, and the mistake was noticed by sashiko when
reviewing this one.
Paolo
next prev parent reply other threads:[~2026-08-05 14:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 16:43 [PATCH RFT 0/3] mm, drm: ensure .fault() does not have to be followed by .pfn_mkwrite() for write faults Paolo Bonzini
2026-07-31 16:43 ` [PATCH RFT 1/3] mm: export variants of vmf_insert_pfn* for use with pfn_mkwrite() Paolo Bonzini
2026-08-03 12:16 ` David Hildenbrand (Arm)
2026-08-04 13:52 ` Christoph Hellwig
2026-08-04 14:35 ` Paolo Bonzini
2026-07-31 16:43 ` [PATCH RFT 2/3] drm/shmem_helper: use vmf_insert_pfn_mkwrite() Paolo Bonzini
2026-07-31 17:06 ` sashiko-bot
2026-08-03 9:55 ` Boris Brezillon
2026-07-31 16:43 ` [PATCH RFT 3/3] drm/ttm, drm/vmwgfx: directly create writable PTEs when mkwrite is in use Paolo Bonzini
2026-07-31 17:04 ` sashiko-bot
2026-08-05 12:58 ` Christian König
2026-08-05 14:48 ` Paolo Bonzini [this message]
2026-08-03 7:30 ` [PATCH RFT 0/3] mm, drm: ensure .fault() does not have to be followed by .pfn_mkwrite() for write faults Sergio Lopez Pascual
2026-08-03 11:54 ` David Hildenbrand (Arm)
2026-08-03 14:19 ` Paolo Bonzini
2026-08-03 15:18 ` David Hildenbrand (Arm)
2026-08-04 7:50 ` Paolo Bonzini
2026-08-04 12:19 ` David Hildenbrand (Arm)
2026-08-03 16:52 ` 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=12bd995c-e320-47c9-adb1-fff3a14bddc7@redhat.com \
--to=pbonzini@redhat.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=boris.brezillon@collabora.com \
--cc=christian.koenig@amd.com \
--cc=david@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=ray.huang@amd.com \
--cc=slp@redhat.com \
--cc=tzimmermann@suse.de \
/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.