[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



On 03.09.2019 18:14, Roger Pau Monne wrote:
> --- 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 *);

If you omit the latter two parameter names, the first one should
be omitted, too. And if there was to be any inconsistency in this
regard, then the one parameter where the type doesn't immediately
clarify the purpose would be the one to have a name.

As to the struct vcpu * parameter - is there an expectation that
the handler would be called with this being other than "current"?
If not, the parameter would want to either be dropped, or be
named "curr".

Jan

_______________________________________________
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®.