> > +/* Use the 2nd 64-page range to exercise a non-zero offset. */
> > +#define TEST_CLEAR_LOG_FIRST_PAGE 64
> > +#define TEST_CLEAR_LOG_NUM_PAGES 64
> > +#define TEST_CLEAR_LOG_BIT 1
> > +#define TEST_CLEAR_LOG_PAGE (TEST_CLEAR_LOG_FIRST_PAGE + \
> > + TEST_CLEAR_LOG_BIT)
> > +static void guest_code_clear_log(void)
> > +{
> > + u64 addr = guest_test_virt_mem + TEST_CLEAR_LOG_PAGE * host_page_size;
> > +
> > + while (true) {
> > + vcpu_arch_put_guest(*(u64 *)addr, 1);
>
> [Severity: Medium]
> Will this result in an out-of-bounds guest memory access on architectures
> where
> the host page size is larger than the guest page size?
Agreed.
The allocation is sized in guest pages, but the clear request and
guest write offset are expressed in host pages.
I'll fix this in v2 by starting with 3*64=192 host pages and
converting that count to guest pages before applying the allocation
adjustment.
> > + kvm_vm_get_dirty_log(vm, TEST_MEM_SLOT_INDEX, bmap);
> > + for (page = 0; page < host_num_pages; page++)
> > + TEST_ASSERT(test_bit_le(page, bmap),
> > + "Page %lu should be dirty after INITIALLY_SET",
> > page);
>
> [Severity: Medium]
> Does this assertion assume that KVM_DIRTY_LOG_INITIALLY_SET is always
> supported
> if KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is present?
> Sashiko AI review ยท
> https://sashiko.dev/#/patchset/[email protected]?part=1
Agreed.
I'll check for the KVM_DIRTY_LOG_INITIALLY_SET at the start of the
test, and skip the test if it is unavailable.
