On Mon, Nov 14, 2022 at 11:37 AM Peter Gonda <pgonda@xxxxxxxxxx> wrote:
>...
> > +static void handle_vm_exit_map_gpa_hypercall(struct kvm_vm *vm,
> > + struct kvm_vcpu *vcpu)
> > +{
> > + uint64_t gpa, npages, attrs, size;
> > +
> > + TEST_ASSERT(vcpu->run->hypercall.nr == KVM_HC_MAP_GPA_RANGE,
> > + "Unhandled Hypercall %lld\n", vcpu->run->hypercall.nr);
> > + gpa = vcpu->run->hypercall.args[0];
> > + npages = vcpu->run->hypercall.args[1];
> > + size = npages << MIN_PAGE_SHIFT;
> > + attrs = vcpu->run->hypercall.args[2];
> > + pr_info("Explicit conversion off 0x%lx size 0x%lx to %s\n", gpa, size,
> > + (attrs & KVM_MAP_GPA_RANGE_ENCRYPTED) ? "private" : "shared");
> > +
> > + if (attrs & KVM_MAP_GPA_RANGE_ENCRYPTED)
> > + vm_allocate_private_mem(vm, gpa, size);
> > + else
> > + vm_unback_private_mem(vm, gpa, size);
> > +
> > + vcpu->run->hypercall.ret = 0;
> > +}
> > +
> > +static void vcpu_work(struct kvm_vm *vm, struct kvm_vcpu *vcpu,
> > + struct vm_setup_info *info)
> > +{
> > + struct ucall uc;
> > + uint64_t cmd;
> > +
> > + /*
> > + * Loop until the guest is done.
> > + */
> > +
> > + while (true) {
> > + vcpu_run(vcpu);
> > +
> > + if (vcpu->run->exit_reason == KVM_EXIT_IO) {
> > + cmd = get_ucall(vcpu, &uc);
> > + if (cmd != UCALL_SYNC)
> > + break;
> > +
> > + TEST_ASSERT(info->ioexit_cb, "ioexit cb not present");
> > + info->ioexit_cb(vm, uc.args[1]);
> > + continue;
> > + }
>
> Should this be integrated into the ucall library directly somehow?
> That way users of VMs with private memory do not need special
> handling?
>
> After Sean's series:
> https://lore.kernel.org/linux-arm-kernel/20220825232522.3997340-3-seanjc@xxxxxxxxxx/
> we have a common get_ucall() that this check could be integrated into?
>
> > +
> > + if (vcpu->run->exit_reason == KVM_EXIT_HYPERCALL) {
> > + handle_vm_exit_map_gpa_hypercall(vm, vcpu);
> > + continue;
> > + }
> > +
> > + TEST_FAIL("Unhandled VCPU exit reason %d\n",
> > + vcpu->run->exit_reason);
> > + break;
> > + }
> > +
> > + if (vcpu->run->exit_reason == KVM_EXIT_IO && cmd == UCALL_ABORT)
> > + TEST_FAIL("%s at %s:%ld, val = %lu", (const char *)uc.args[0],
> > + __FILE__, uc.args[1], uc.args[2]);
> > +}
> > +
> > +/*
> > + * Execute guest vm with private memory memslots.
> > + *
> > + * Input Args:
> > + * info - pointer to a structure containing information about setting up a VM
> > + * with private memslots
> > + *
> > + * Output Args: None
> > + *
> > + * Return: None
> > + *
> > + * Function called by host userspace logic in selftests to execute guest vm
> > + * logic. It will install test_mem_slot : containing the region of memory that
> > + * would be used to test private/shared memory accesses to a memory backed by
> > + * private memslots
> > + */
> > +void execute_vm_with_private_test_mem(struct vm_setup_info *info)
> > +{
> > + struct kvm_vm *vm;
> > + struct kvm_enable_cap cap;
> > + struct kvm_vcpu *vcpu;
> > + uint64_t test_area_gpa, test_area_size;
> > + struct test_setup_info *test_info = &info->test_info;
> > +
> > + TEST_ASSERT(info->guest_fn, "guest_fn not present");
> > + vm = vm_create_with_one_vcpu(&vcpu, info->guest_fn);
>
> I am a little confused with how this library is going to work for SEV
> VMs that want to have UPM private memory eventually.
>
> Why should users of UPM be forced to use this very specific VM
> creation and vCPU run loop. In the patch
> https://lore.kernel.org/lkml/20220829171021.701198-1-pgonda@xxxxxxxxxx/T/#m033ebc32df47a172bc6c46d4398b6c4387b7934d
> SEV VMs need to be created specially vm_sev_create_with_one_vcpu() but
> then callers can run the VM's vCPUs like other selftests.
>
> How do you see this working with SEV VMs?
>
This VM creation method can be useful to run the VMs whose execution
might call mapgpa to change the memory attributes. New VM creation
method specific to Sev VMs can be introduced.
I tried to reuse this framework earlier for Sev VM selftests via:
1) https://lore.kernel.org/lkml/20220830224259.412342-8-vannapurve@xxxxxxxxxx/T/#m8164d3111c9a17ebab77f01635df8930207cc65d
2) https://lore.kernel.org/lkml/20220830224259.412342-8-vannapurve@xxxxxxxxxx/T/#m8164d3111c9a17ebab77f01635df8930207cc65d
Though these changes need to be refreshed after this updated series.
