[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/2] x86/HVM: expose VM assist hypercall

On 14/04/2020 12:34, Jan Beulich wrote:
> In preparation for the addition of VMASST_TYPE_runstate_update_flag
> commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
> the hypercall for Arm. I consider it not logical that it then isn't also
> exposed to x86 HVM guests (with the same single feature permitted to be
> enabled as Arm has); Linux actually tries to use it afaict.
> Rather than introducing yet another thin wrapper around vm_assist(),
> make that function the main handler, requiring a per-arch
> arch_vm_assist_valid() definition instead.
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v2: Re-work vm_assist() handling/layering at the same time. Also adjust
>     arch_set_info_guest().

Much nicer.  Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

However, ...

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1517,20 +1517,23 @@ long do_vcpu_op(int cmd, unsigned int vc
>      return rc;
>  }
> -long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
> -               unsigned long valid)
> +#ifdef arch_vm_assist_valid
> +long do_vm_assist(unsigned int cmd, unsigned int type)
>  {
> +    struct domain *currd = current->domain;
> +    const unsigned long valid = arch_vm_assist_valid(currd);
> +
>      if ( type >= BITS_PER_LONG || !test_bit(type, &valid) )
>          return -EINVAL;

As a thought, would it be better to have a guest_bits_per_long()
helper?  This type >= BITS_PER_LONG isn't terribly correct for 32bit
guests, and it would avoid needing the truncation in the arch helper,
which is asymmetric on the ARM side.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.