2018-12-20 16:36+0100, Andrew Jones:
> Dan pointed out the unsigned less than zero comparison and Paolo
> suggested a different approach to the iteration. I pulled together
> something that also ensures we maintain page aligned addresses
> by using power-of-two divisors (8 and 16) and fixes two other bugs.
> The first other bug was that the start and step calculations were
> wrong since they were dividing the number of address bits instead
> of the address space. The second other bug was that the guessing
> algorithm wasn't considering the valid physical and virtual address
> ranges correctly for an identity map. Sigh... Hopefully we've finally
> got this thing right!
Paolo actually sneaked in a fix for this already, 5132411985e1 ("kvm:
selftests: ucall: improve ucall placement in memory, fix unsigned
comparison"), so the physical range fix should come on top.
> Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> Signed-off-by: Andrew Jones <drjones@xxxxxxxxxx>
> ---
> diff --git a/tools/testing/selftests/kvm/lib/ucall.c b/tools/testing/selftests/kvm/lib/ucall.c
> @@ -45,25 +46,30 @@ void ucall_init(struct kvm_vm *vm, ucall_type_t type, void *arg)
> }
>
> /*
> - * Find an address within the allowed virtual address space,
> - * that does _not_ have a KVM memory region associated with it.
> - * Identity mapping an address like this allows the guest to
> + * Find an address within the allowed physical and virtual address
> + * spaces, that does _not_ have a KVM memory region associated with
> + * it. Identity mapping an address like this allows the guest to
> * access it, but as KVM doesn't know what to do with it, it
> * will assume it's something userspace handles and exit with
> * KVM_EXIT_MMIO. Well, at least that's how it works for AArch64.
> - * Here we start with a guess that the addresses around two
> - * thirds of the VA space are unmapped and then work both down
> - * and up from there in 1/6 VA space sized steps.
> + * Here we start with a guess that the addresses around 5/8th
> + * of the allowed space are unmapped and then work both down and
> + * up from there in 1/16th allowed space sized steps.
> + *
> + * Note, we need to use VA-bits - 1 when calculating the allowed
> + * virtual address space for an identity mapping because the upper
> + * half of the virtual address space is the two's complement of the
> + * lower and won't match physical addresses.
Do you mean the split address space due to cannonical address encoding
in e.g. x86? (It's more like sign extension.)
We could leave the canonization to architectural code, instead of
halving the range in that case.
> */
> - start = 1ul << (vm->va_bits * 2 / 3);
> - end = 1ul << vm->va_bits;
> - step = 1ul << (vm->va_bits / 6);
> - for (gpa = start; gpa >= 0; gpa -= step) {
> - if (ucall_mmio_init(vm, gpa & ~(vm->page_size - 1)))
> + bits = vm->va_bits - 1;
> + bits = vm->pa_bits < bits ? vm->pa_bits : bits;
> + end = 1ul << bits;
I'd use MIN(va, pa) directly in end computation, even though it's
unlikely we'll get more physical bits than virtual.
Thanks.
