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

Re: [PATCH v6 1/9] xen: move do_vcpu_op() to arch specific code


  • To: Juergen Gross <jgross@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 27 Jun 2022 15:00:43 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nSXkb4yNA8FmX5diu9PcRef5S45fTEAnQSpEMy9qVRo=; b=dGWx8TjAVr6gUYEl1lg9RdB7wjYnZv642KR408HLuOcmo2mvwqECZl6pVK/H7dZbH3k2cKb7u0/qCxiT9gdOZ4o2WI/a9jxYorfwX3YcvHEYCAMxrRga1PuQHVNz10jo1Gy3YUJytNW71HEUJQ2KrRuKw4TEahcmjXTGde90idx/mVteDKvzRozwz+Zas2kVvPBvyKMmDS4wHhPxD4wKZoA7lVEJI3bJNwJCFMGpJIWo1VaX4NIu92IWaqCmx9w2J1vTJP4Xl7YNs5e+BkOqg+zsPMKsUN718LYwDe5fzKVmwBpyOjHRWcwPhTU+AWxJNAgANOz7fotNogQ5n+FGVA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aUueZEcdHtEtLc7bk1ae9yNJCbW2BmFGQc0nJA0dE7s/OkOlP3wCx/P+CP7AQK6tK9ZtlS2R2l7vUVSlcLPKb/HJmmkW+XWVq/dz4kfVIvG4bZBBaa/OJpSfjXJAFPJSGhZfU+dGixhCop6gKSmRs/g0JeXbf9R9KWYrdzltufbD/eOn9E965Dh720F+YG39luOSWqST7nBJmIiI49oB0OChOxxde+tesR1PMA0o5dRfZ1G/DEoRgR7EOtls8VjjLpbuv1HB971QlKB9HdwwTjpTBUoGo/Nw/mjVrcxK2nQgs9D+eEd2jckCGYc/mV3RNMOPJ85hxbNnJdUbP4wIPA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <jgrall@xxxxxxxxxx>
  • Delivery-date: Mon, 27 Jun 2022 13:01:20 +0000
  • Ironport-data: A9a23:56jXQK7FOVV3yiyKg0+VVAxRtM7GchMFZxGqfqrLsTDasY5as4F+v jcdCD/QO/+NMGukLYhyYdi1/RlV78KGnd83QAtp/isxHi5G8cbLO4+Ufxz6V8+wwmwvb67FA +E2MISowBUcFyeEzvuVGuG96yE6j8lkf5KkYAL+EnkZqTRMFWFw03qPp8Zj2tQy2YbjXFvU0 T/Pi5a31GGNimYc3l08s8pvmDs31BglkGpF1rCWTakjUG72zxH5PrpGTU2CByKQrr1vNvy7X 47+IISRpQs1yfuP5uSNyd4XemVSKlLb0JPnZnB+A8BOiTAazsA+PzpS2FPxpi67hh3Q9+2dx umhurSaaV80P5bBtN43DQsfGQJPHfVt8ubudC3XXcy7lyUqclPK6tA3VgQcG91d/ex6R2ZT6 fYfNTYBKAiZgP67y666Te8qgdk/KM7sP8UUvXQIITPxVK56B8ycBfiXo4YHhF/chegXdRraT 9AeZjd1KgzJfjVEO0sNCYJ4l+Ct7pX6W2ID+AjL/vVui4TV5E8pgZ71CtvuRuGHZ8dlkky+u 2380U2sV3n2M/Tak1Jp6EmEhODVmjjgcJkPD7D+/flv6HWDy2pWBBAIWF+TpfiillX4S99ZM 1YT+Cclse417kPDZsLmQxSyrXqAvxgdc9ldCes37EeK0KW8ywSEAmkJSBZRZdpgs9U5LRQg2 0WVhdrvCXpquaeMVHOG3r6OqHW5Pi19BVEFYSgIXA4U+e7JqYs4jg/MZtt7GavzhdrwcRnyy T2XqCk1h50IkNUGka68+DjvnDaEtpXPCAkv6W3/XG2/5wd9TIegbp6v7x7Q6vMoEWqCZlyIv XxBkc7O6ukLVMuJjHbUH71LG6y17fGYNjGamURoA5Qq6zWq/TikYJxU5zZ9YkxuN67oZAPUX aMagisJjLc7AZdgRfYfj16ZYyjy8ZXdKA==
  • Ironport-hdrordr: A9a23:ioafdqMehqIyR8BcT1r155DYdb4zR+YMi2TDiHoddfUFSKalfp 6V98jztSWatN/eYgBEpTmlAtj5fZq6z+8P3WBxB8baYOCCggeVxe5ZjbcKrweQeBEWs9Qtr5 uIEJIOd+EYb2IK6voSiTPQe7hA/DDEytHPuQ639QYQcegAUdAF0+4WMHf4LqUgLzM2eKbRWa DskPZvln6FQzA6f867Dn4KU6zqoMDKrovvZVojCwQ84AeDoDu04PqieiLolis2Yndq+/MP4G LFmwv26uGKtOy68AbV0yv2445NkNXs59NfDIini9QTKB/rlgG0Db4REoGqjXQQmqWC+VwqmN 7Dr1MJONly0WrYeiWPrR7ky2DboUMTwk6n7WXdrWrooMT/Sj5/IdFGn5hlfhzQ7FdllM1g0Y pQtljp+6Z/PFflpmDQ9tLIXxZlmg6funw5i9MeiHRZTM83dKJRl4oC50lYea1wUR4S0LpXXt WGMfuspcq/KTihHjDkVyhUsZaRt00Ib1i7qhNogL3X79BU9EoJvXfwivZv3Evoz6hNOqWs19 60TJiAq4s+PvP+TZgNcNvpEvHHfVDlcFbrDF+4B2jBOeUuB0/twqSHk4ndotvaM6A18A==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Mar 24, 2022 at 03:01:31PM +0100, Juergen Gross wrote:
> The entry point used for the vcpu_op hypercall on Arm is different
> from the one on x86 today, as some of the common sub-ops are not
> supported on Arm. The Arm specific handler filters out the not
> supported sub-ops and then calls the common handler. This leads to the
> weird call hierarchy:
> 
>   do_arm_vcpu_op()
>     do_vcpu_op()
>       arch_do_vcpu_op()
> 
> Clean this up by renaming do_vcpu_op() to common_vcpu_op() and
> arch_do_vcpu_op() in each architecture to do_vcpu_op(). This way one
> of above calls can be avoided without restricting any potential
> future use of common sub-ops for Arm.
> 
> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> Reviewed-by: Julien Grall <jgrall@xxxxxxxxxx>

Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxxx>

>From an x86 only PoV I prefer the previous arrangement (do_vcpu_op() ->
arch_do_vcpu_op()), but this approach seems to be better for Arm, so
that's a reasonable argument for changing it.

My preference would have been to move the handling of hypercalls not
used by Arm into arch_do_vcpu_op() for x86, but that's also not widely
liked.

> ---
> V4:
> - don't remove HYPERCALL_ARM()
> V4.1:
> - add missing cf_check (Andrew Cooper)
> V5:
> - use v instead of current (Julien Grall)
> ---
>  xen/arch/arm/domain.c                | 15 ++++++++-------
>  xen/arch/arm/include/asm/hypercall.h |  2 --
>  xen/arch/arm/traps.c                 |  2 +-
>  xen/arch/x86/domain.c                | 12 ++++++++----
>  xen/arch/x86/include/asm/hypercall.h |  2 +-
>  xen/arch/x86/x86_64/domain.c         | 18 +++++++++++++-----
>  xen/common/compat/domain.c           | 15 ++++++---------
>  xen/common/domain.c                  | 12 ++++--------
>  xen/include/xen/hypercall.h          |  2 +-
>  9 files changed, 42 insertions(+), 38 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 8110c1df86..2f8eaab7b5 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -1079,23 +1079,24 @@ void arch_dump_domain_info(struct domain *d)
>  }
>  
>  
> -long do_arm_vcpu_op(int cmd, unsigned int vcpuid, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
> +long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
> arg)
>  {
> +    struct domain *d = current->domain;
> +    struct vcpu *v;
> +
> +    if ( (v = domain_vcpu(d, vcpuid)) == NULL )
> +        return -ENOENT;

My preference (here and in x86) code would be to do the initialization
at definition, and then just check for v here, ie:

struct vcpu *v = domain_vcpu(d, vcpuid);

if ( !v )
    return -ENOENT;

But that's just my taste.

Thanks, Roger.



 


Rackspace

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