On Wed, Mar 13, 2024, Christian König wrote: > Am 13.03.24 um 14:34 schrieb Sean Christopherson: > > On Wed, Mar 13, 2024, Christian König wrote: > > > And when you have either of those two functionalities the requirement to add > > > a long term reference to the struct page goes away completely. So when this > > > is done right you don't need to grab a reference in the first place. > > The KVM issue that this series is solving isn't that KVM grabs a reference, it's > > that KVM assumes that any non-reserved pfn that is backed by "struct page" is > > refcounted. > > Well why does it assumes that? When you have a MMU notifier that seems > unnecessary. Indeed, it's legacy code that we're trying to clean up. It's the bulk of this series. > > What Christoph is objecting to is that, in this series, KVM is explicitly adding > > support for mapping non-compound (huge)pages into KVM guests. David is arguing > > that Christoph's objection to _KVM_ adding support is unfair, because the real > > problem is that the kernel already maps such pages into host userspace. I.e. if > > the userspace mapping ceases to exist, then there are no mappings for KVM to follow > > and propagate to KVM's stage-2 page tables. > > And I have to agree with Christoph that this doesn't make much sense. KVM > should *never* map (huge) pages from VMAs marked with VM_PFNMAP into KVM > guests in the first place. > > What it should do instead is to mirror the PFN from the host page tables > into the guest page tables. That's exactly what this series does. Christoph is objecting to KVM playing nice with non-compound hugepages, as he feels that such mappings should not exist *anywhere*. I.e. Christoph is (implicitly) saying that instead of modifying KVM to play nice, we should instead fix the TTM allocations. And David pointed out that that was tried and got NAK'd.
