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

Re: [Xen-devel] [PATCH v2 04/11] ioreq: add fields to allow internal ioreq servers



> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Roger 
> Pau Monne
> Sent: 03 September 2019 17:14
> To: xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>; Jan 
> Beulich <jbeulich@xxxxxxxx>;
> Roger Pau Monne <roger.pau@xxxxxxxxxx>
> Subject: [Xen-devel] [PATCH v2 04/11] ioreq: add fields to allow internal 
> ioreq servers
> 
> Internal ioreq servers are plain function handlers implemented inside
> of the hypervisor. Note that most fields used by current (external)
> ioreq servers are not needed for internal ones, and hence have been
> placed inside of a struct and packed in an union together with the
> only internal specific field, a function pointer to a handler.
> 
> This is required in order to have PCI config accesses forwarded to
> external ioreq servers or to internal ones (ie: QEMU emulated devices
> vs vPCI passthrough), and is the first step in order to allow
> unprivileged domains to use vPCI.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

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

> ---
> Changes since v1:
>  - Do not add an internal field to the ioreq server struct, whether a
>    server is internal or external can already be inferred from the id.
>  - Add an extra parameter to the internal handler in order to pass
>    user-provided opaque data to the handler.
> ---
>  xen/include/asm-x86/hvm/domain.h | 30 +++++++++++++++++++-----------
>  1 file changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/include/asm-x86/hvm/domain.h 
> b/xen/include/asm-x86/hvm/domain.h
> index bcc5621797..9fbe83f45a 100644
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -52,21 +52,29 @@ struct hvm_ioreq_vcpu {
>  #define MAX_NR_IO_RANGES  256
> 
>  struct hvm_ioreq_server {
> -    struct domain          *target, *emulator;
> -
> +    struct domain          *target;
>      /* Lock to serialize toolstack modifications */
>      spinlock_t             lock;
> -
> -    struct hvm_ioreq_page  ioreq;
> -    struct list_head       ioreq_vcpu_list;
> -    struct hvm_ioreq_page  bufioreq;
> -
> -    /* Lock to serialize access to buffered ioreq ring */
> -    spinlock_t             bufioreq_lock;
> -    evtchn_port_t          bufioreq_evtchn;
>      struct rangeset        *range[NR_IO_RANGE_TYPES];
>      bool                   enabled;
> -    uint8_t                bufioreq_handling;
> +
> +    union {
> +        struct {
> +            struct domain          *emulator;
> +            struct hvm_ioreq_page  ioreq;
> +            struct list_head       ioreq_vcpu_list;
> +            struct hvm_ioreq_page  bufioreq;
> +
> +            /* Lock to serialize access to buffered ioreq ring */
> +            spinlock_t             bufioreq_lock;
> +            evtchn_port_t          bufioreq_evtchn;
> +            uint8_t                bufioreq_handling;
> +        };
> +        struct {
> +            void                   *data;
> +            int (*handler)(struct vcpu *v, ioreq_t *, void *);
> +        };
> +    };
>  };
> 
>  /*
> --
> 2.22.0
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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