On Thu, Mar 14, 2024 at 12:51:40PM +0100, Christian König wrote: > > Does Christoph's objection come from my poorly worded cover letter and > > commit messages, then? > > Yes, that could certainly be. That's definitively a big part of it, but I think not the only one. > > Fundamentally, what this series is doing is > > allowing pfns returned by follow_pte to be mapped into KVM's shadow > > MMU without inadvertently translating them into struct pages. > > As far as I can tell that is really the right thing to do. Yes. IFF your callers don't need pages and you just want to track the mapping in the shadow mmu and never take a refcount that is a good thing. But unless I completely misunderstood the series that doesn't seem to be the case - it builds a new kvm_follow_pfn API which is another of these weird multiplexers like get_user_pages that can to tons of different things depending on the flags. And some of that still grabs the refcount, right? > Completely agree. In my thinking when you go a step further and offload > grabbing the page reference to get_user_pages() then you are always on the > save side. Agreed. > Because then it is no longer the responsibility of the KVM code to get all > the rules around that right, instead you are relying on a core functionality > which should (at least in theory) do the correct thing. Exactly.
