Michael Roth <michael.roth@xxxxxxx> writes:
> On Fri, Apr 18, 2025 at 08:13:17AM -0700, Sean Christopherson wrote:
>>
>> That all looks good to me. And to ensure we don't go off the rails due to bad
>> inputs (which are supposed to be fully validated by common KVM), we could add a
>> WARN to detect a non-exclusive range->end.
>>
>> So this?
>>
>> if (WARN_ON_ONCE(range->end <= range->start))
>> return false;
>>
>> /*
>> * If the head and tail pages of the range currently allow a hugepage,
>> * i.e. reside fully in the slot and don't have mixed attributes, then
>> * add each corresponding hugepage range to the ongoing invalidation,
>> * e.g. to prevent KVM from creating a hugepage in response to a fault
>> * for a gfn whose attributes aren't changing. Note, only the range
>> * of gfns whose attributes are being modified needs to be explicitly
>> * unmapped, as that will unmap any existing hugepages.
>> */
>> for (level = PG_LEVEL_2M; level <= KVM_MAX_HUGEPAGE_LEVEL; level++) {
>> gfn_t start = gfn_round_for_level(range->start, level);
>> gfn_t end = gfn_round_for_level(range->end - 1, level);
>> gfn_t nr_pages = KVM_PAGES_PER_HPAGE(level);
>>
>> if ((start != range->start || start + nr_pages > range->end) &&
>> start >= slot->base_gfn &&
>> start + nr_pages <= slot->base_gfn + slot->npages &&
>> !hugepage_test_mixed(slot, start, level))
>> kvm_mmu_invalidate_range_add(kvm, start, start + nr_pages);
>>
>> if (end == start)
>> continue;
>>
>> if ((end + nr_pages) <= (slot->base_gfn + slot->npages) &&
>> !hugepage_test_mixed(slot, end, level))
>> kvm_mmu_invalidate_range_add(kvm, end, end + nr_pages);
>> }
>
> Looks good! Re-tested with this version of the patch and it seems to address
> the original issue.
>
> Tested-by: Michael Roth <michael.roth@xxxxxxx>
>
> Thanks,
>
> Mike
Would you be able to share how you set up a test to trigger this issue?
Thanks in advance!
