Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of
> Andrew Cooper
> Sent: 13 July 2017 09:51
> To: Xen-devel <xen-devel@xxxxxxxxxxxxx>
> Cc: Juergen Gross <jgross@xxxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; Andrew Cooper
> <Andrew.Cooper3@xxxxxxxxxx>; Julien Grall <julien.grall@xxxxxxx>; Jan
> Beulich <JBeulich@xxxxxxxx>; Roger Pau Monne <roger.pau@xxxxxxxxxx>
> Subject: [Xen-devel] [PATCH RFC] xen/evtchn: Implement
> EVTCHNOP_send_imm as a companian to EVTCHNOP_send
> 
> The event channel ABI passes a pointer to a subop-specific structure.  Some
> of
> these structures however are smaller than the pointers passed in the ABI;
> EVTCHNOP_send specifically passes a 4 byte evtchn port, using a 4 or 8 byte
> pointer.
> 
> For translated guests (x86 HVM and all ARM), passing the port number
> directly
> avoids a guest pagetable walk, which can be very expensive for Xen to
> perform.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

LGTM. I suspect this will help performance of PV drivers quite a bit.

Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>

> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> CC: Julien Grall <julien.grall@xxxxxxx>
> CC: Juergen Gross <jgross@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Wei Liu <wei.liu2@xxxxxxxxxx>
> 
> RFC: is it worth converting the close, unmask, reset (and possibly
> expand_array) as well?
> ---
>  xen/common/event_channel.c         |  4 ++++
>  xen/include/public/event_channel.h | 13 ++++++++++---
>  2 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index c69f9db..79d8614 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1098,6 +1098,10 @@ long do_event_channel_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>          break;
>      }
> 
> +    case EVTCHNOP_send_imm:
> +        rc = evtchn_send(current->domain, (unsigned long)arg.p);
> +        break;
> +
>      case EVTCHNOP_status: {
>          struct evtchn_status status;
>          if ( copy_from_guest(&status, arg, 1) != 0 )
> diff --git a/xen/include/public/event_channel.h
> b/xen/include/public/event_channel.h
> index 44c549d..834787a 100644
> --- a/xen/include/public/event_channel.h
> +++ b/xen/include/public/event_channel.h
> @@ -57,6 +57,9 @@
>   * `
>   * @cmd  == EVTCHNOP_* (event-channel operation).
>   * @args == struct evtchn_* Operation-specific extra arguments (NULL if
> none).
> + *
> + * For @cmd with an _imm suffix, data are passed as an integer, rather than
> a
> + * pointer to a structure.
>   */
> 
>  /* ` enum event_channel_op { // EVTCHNOP_* => struct evtchn_* */
> @@ -64,7 +67,7 @@
>  #define EVTCHNOP_bind_virq        1
>  #define EVTCHNOP_bind_pirq        2
>  #define EVTCHNOP_close            3
> -#define EVTCHNOP_send             4
> +#define EVTCHNOP_send             4 /* Deprecated.  Use
> EVTCHNOP_send_imm in preference. */
>  #define EVTCHNOP_status           5
>  #define EVTCHNOP_alloc_unbound    6
>  #define EVTCHNOP_bind_ipi         7
> @@ -74,6 +77,7 @@
>  #define EVTCHNOP_init_control    11
>  #define EVTCHNOP_expand_array    12
>  #define EVTCHNOP_set_priority    13
> +#define EVTCHNOP_send_imm        14
>  /* ` } */
> 
>  typedef uint32_t evtchn_port_t;
> @@ -186,8 +190,11 @@ struct evtchn_close {
>  typedef struct evtchn_close evtchn_close_t;
> 
>  /*
> - * EVTCHNOP_send: Send an event to the remote end of the channel
> whose local
> - * endpoint is <port>.
> + * EVTCHNOP_send{,_imm}: Send an event to the remote end of the
> channel whose
> + * local endpoint is <port>.
> + *
> + * For EVTCHNOP_send, arg is a pointer to an evtchn_send_t.  For
> + * EVTCHNOP_send_imm, arg is the port directly.
>   */
>  struct evtchn_send {
>      /* IN parameters. */
> --
> 2.1.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel