Re: [PATCH v4 30/31] i386/kvm: Add KVM_EXIT_HYPERCALL handling for KVM_HC_MAP_GPA_RANGE

[Binbin Wu <binbin.wu@linux.intel.com>]

On 5/30/2024 7:16 PM, Pankaj Gupta wrote:

[...]
> +/*
> + * Currently the handling here only supports use of KVM_HC_MAP_GPA_RANGE
> + * to service guest-initiated memory attribute update requests so that
> + * KVM_SET_MEMORY_ATTRIBUTES can update whether or not a page should be
> + * backed by the private memory pool provided by guest_memfd, and as such
> + * is only applicable to guest_memfd-backed guests (e.g. SNP/TDX).
> + *
> + * Other other use-cases for KVM_HC_MAP_GPA_RANGE, such as for SEV live
            ^
            extra "other"?
> + * migration, are not implemented here currently.
> + *
> + * For the guest_memfd use-case, these exits will generally be synthesized
> + * by KVM based on platform-specific hypercalls, like GHCB requests in the
> + * case of SEV-SNP, and not issued directly within the guest though the
> + * KVM_HC_MAP_GPA_RANGE hypercall. So in this case, KVM_HC_MAP_GPA_RANGE is
> + * not actually advertised to guests via the KVM CPUID feature bit, as
> + * opposed to SEV live migration where it would be. Since it is unlikely the
> + * SEV live migration use-case would be useful for guest-memfd backed guests,
> + * because private/shared page tracking is already provided through other
> + * means, these 2 use-cases should be treated as being mutually-exclusive.
> + */
> +static int kvm_handle_hc_map_gpa_range(struct kvm_run *run)
> +{
> +    uint64_t gpa, size, attributes;
> +
> +    if (!machine_require_guest_memfd(current_machine))
> +        return -EINVAL;
> +
> +    gpa = run->hypercall.args[0];
> +    size = run->hypercall.args[1] * TARGET_PAGE_SIZE;
> +    attributes = run->hypercall.args[2];
> +
> +    trace_kvm_hc_map_gpa_range(gpa, size, attributes, run->hypercall.flags);
> +
> +    return kvm_convert_memory(gpa, size, attributes & KVM_MAP_GPA_RANGE_ENCRYPTED);

run->hypercall.ret should be updated accordingly.
At least for successful case.
For failure case, QEMU will shutdown the VM, is it the expected behavior?


> +}
> +
> +static int kvm_handle_hypercall(struct kvm_run *run)
> +{
> +    if (run->hypercall.nr == KVM_HC_MAP_GPA_RANGE)
> +        return kvm_handle_hc_map_gpa_range(run);
> +
> +    return -EINVAL;
> +}
> +
>
[...]