[CCing Paolo and Sergio] On 8/4/26 16:57, Konstantin Fastov wrote: > вт, 4 авг. 2026 г. в 17:29, Boris Brezillon <[email protected]>: >> On Tue, 4 Aug 2026 17:04:03 +0300 >> Konstantin Fastov <[email protected]> wrote: >> >>> Since the introduction of dirty tracking, drm_gem_shmem_vm_ops has a >>> .pfn_mkwrite handler. Its presence makes vma_wants_writenotify() true, >>> so vma_set_page_prot() removes the write bit from vm_page_prot of >>> shared mappings, and the vmf_insert_pfn() call in the fault handler now >>> installs read-only PTEs even when serving a write fault. >>> >>> For regular CPU accesses this is transparent: the retried access faults >>> again on the present read-only PTE, goes through wp_pfn_shared() into >>> .pfn_mkwrite() and the PTE is upgraded to writable. But consumers that >>> resolve faults through fixup_user_fault() + follow_pfnmap_start() >>> perform no such retry. In particular KVM's hva_to_pfn_remapped(), >>> after "successfully" handling a write fault, finds a present read-only >>> PTE, treats it as KVM_PFN_ERR_RO_FAULT and fails the vcpu run with >>> EFAULT. Observed as AsahiLinux/linux#560: muvm/libkrun microVMs >>> mapping virtio-gpu blob resources die with EFAULT on first GPU access. >>> The traced failing sequence: [...] >> >> The same issue is being discussed here [1]. >> [...] >> [1]https://lore.kernel.org/dri-devel/[email protected]/ > > Thanks, I missed that series, I searched dri-devel but not the kvm list. > Paolo's patches 1-2 are indeed the same fix (down to the same function > name), so please consider my patch superseded by his series. [...] FWIW, it seems that series takes a while to get polished and mainlined: https://lore.kernel.org/all/cabgobfygz87%3dw%2b6e%3dn%[email protected]/
To quote: "It ballooned a bit and getting acks from everyone involved is hard... Either I or Sergio will get back to it." Is that something you/AsahiLinux/the world can live with? Ciao, Thorsten
