From: Thomas Zimmermann <tzimmerm...@suse.de> Sent: Monday, June 2, 2025 11:25 PM > > Hi > > Am 03.06.25 um 03:49 schrieb Michael Kelley: > [...] > >> Will the VMA have VM_PFNMAP or VM_MIXEDMAP set? PFN_SPECIAL is a > >> horrible hack. > >> > >> In another thread, you mention that you use PFN_SPECIAL to bypass the > >> check in vm_mixed_ok(), so VM_MIXEDMAP is likely not set? > > The VMA has VM_PFNMAP set, not VM_MIXEDMAP. It seemed like > > VM_MIXEDMAP is somewhat of a superset of VM_PFNMAP, but maybe that's > > a wrong impression. vm_mixed_ok() does a thorough job of validating the > > use of __vm_insert_mixed(), and since what I did was allowed, I thought > > perhaps it was OK. Your feedback has set me straight, and that's what I > > needed. :-) > > > > But the whole approach is moot with Alistair Popple's patch set that > > eliminates pfn_t. Is there an existing mm API that will do mkwrite on a > > special PTE in a VM_PFNMAP VMA? I didn't see one, but maybe I missed > > it. If there's not one, I'll take a crack at adding it in the next version > > of my > > patch set. > > What is the motivation behind this work? The driver or fbdev as a whole > does not have much of a future anyway. > > I'd like to suggest removing hyperv_fb entirely in favor of hypervdrm? >
Yes, I think that's the longer term direction. A couple months ago I had an email conversation with Saurabh Sengar from the Microsoft Linux team where he raised this idea. I think the Microsoft folks will need to drive the deprecation process, as they need to coordinate with the distro vendors who publish images for running on local Hyper-V and in the Azure cloud. And my understanding is that the Linux kernel process would want the driver to be available but marked "deprecated" for a year or so before it actually goes away. I do have some concerns about the maturity of the hyperv_drm driver "around the edges". For example, somebody just recently submitted a patch to flush output on panic. I have less familiarity hyperv_drm vs. hyperv_fb, so some of my concern is probably due to that. We might need to do review of hyperv_drm and see if there's anything else to deal with before hyperv_fb goes away. This all got started when I was looking at a problem with hyperv_fb, and I found several other related problems, some of which also existed in hyperv_drm. You've seen several small'ish fixes from me and Saurabh as a result, and this issue with mmap()'ing /dev/fb0 is the last one of that set. This fix is definitely a bit bigger, but it's the right fix. On the flip side, if we really get on a path to deprecate hyperv_fb, there are hack fixes for the mmap problem that are smaller and contained to hyperv_fb. I would be OK with a hack fix in that case. Michael
