Sean Christopherson <seanjc@xxxxxxxxxx> writes:
> On Fri, Jul 25, 2025, Sean Christopherson wrote:
>> On Thu, Jul 24, 2025, Ackerley Tng wrote:
>> I also don't want to effectively speculatively add kvm_gmem_mapping_order() or
>> expand kvm_gmem_get_pfn(), e.g. to say "no create", so what if we just do this?
>>
>> /* For faults, use the gmem information that was resolved earlier. */
>> if (fault) {
>> pfn = fault->pfn;
>> max_level = fault->max_level;
>> } else {
>> /* TODO: Call into guest_memfd once hugepages are supported. */
>
> Aha! Even better, we can full on WARN:
>
> WARN_ONCE(1, "Get pfn+order from guest_memfd");
>
> Because guest_memfd doesn't yet support dirty logging:
>
> /* Dirty logging private memory is not currently supported. */
> if (mem->flags & KVM_MEM_GUEST_MEMFD)
> valid_flags &= ~KVM_MEM_LOG_DIRTY_PAGES;
>
> which kills off the kvm_mmu_recover_huge_pages() call from kvm_mmu_slot_apply_flags().
> And if KVM ever supports in-place recover for kvm_recover_nx_huge_pages() (which
> is doubtful given that mitigation shouldn't be required going forward), lack of
> hugepage support means any guest_memfd-based shadow page can't be a possible NX
> hugepage.
Thanks, this sounds good!
