[PATCH v4 21/21] KVM: selftests: Test READ=>WRITE dirty logging behavior for shadow MMU
Yosry Ahmed
yosry.ahmed at linux.dev
Thu Jan 8 12:26:07 PST 2026
On Thu, Jan 08, 2026 at 08:32:44AM -0800, Sean Christopherson wrote:
[..]
> @@ -106,12 +139,66 @@ static void l1_guest_code(void *data)
> l1_svm_code(data);
> }
>
> +static void test_handle_ucall_sync(struct kvm_vm *vm, u64 arg,
> + unsigned long *bmap)
> +{
> + vm_vaddr_t gva = arg & ~(PAGE_SIZE - 1);
> + int page_nr, i;
> +
> + /*
> + * Extract the page number of underlying physical page, which is also
> + * the _L1_ page number. The dirty bitmap _must_ be updated based on
> + * the L1 GPA, not L2 GPA, i.e. whether or not L2 used an aliased GPA
> + * (i.e. if TDP enabled for L2) is irrelevant with respect to the dirty
> + * bitmap and which underlying physical page is accessed.
> + *
> + * Note, gva will be '0' if there was no access, i.e. if the purpose of
> + * the sync is to verify all pages are clean.
> + */
> + if (!gva)
> + page_nr = 0;
> + else if (gva >= TEST_MEM_ALIAS_BASE)
> + page_nr = (gva - TEST_MEM_ALIAS_BASE) >> PAGE_SHIFT;
> + else
> + page_nr = (gva - TEST_MEM_BASE) >> PAGE_SHIFT;
> + TEST_ASSERT(page_nr == 0 || page_nr == 1,
> + "Test bug, unexpected frame number '%u' for arg = %lx", page_nr, arg);
> + TEST_ASSERT(gva || (arg & TEST_SYNC_NO_FAULT),
> + "Test bug, gva must be valid if a fault is expected");
> +
> + kvm_vm_get_dirty_log(vm, TEST_MEM_SLOT_INDEX, bmap);
> +
> + /*
> + * Check all pages to verify the correct physical page was modified (or
> + * not), and that all pages are clean/dirty as expected.
> + *
> + * If a fault of any kind is expected, the target page should be dirty
> + * as the Dirty bit is set in the gPTE. KVM should create a writable
> + * SPTE even on a read fault, *and* KVM must mark the GFN as dirty
> + * when doing so.
> + */
> + for (i = 0; i < TEST_MEM_PAGES; i++) {
> + if (i == page_nr && arg & TEST_SYNC_WRITE_FAULT)
Micro nit: I think this is slightly clearer:
if (i == page_nr && (arg & TEST_SYNC_WRITE_FAULT))
More information about the linux-riscv
mailing list