Re: [PATCH v7 5/5] x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Yu Zhang <yu.c.zhang@linux.intel.com>]

On 3/14/2017 9:12 PM, Jan Beulich wrote:
>>>> On 14.03.17 at 13:22, <yu.c.zhang@linux.intel.com> wrote:
>> On 3/14/2017 6:51 PM, Jan Beulich wrote:
>>>>>> On 14.03.17 at 08:42, <yu.c.zhang@linux.intel.com> wrote:
>>>> So you mean change the definition of to
>>>> xen_dm_op_map_mem_type_to_ioreq_server
>>>> to something like this?
>>>>
>>>> struct xen_dm_op_map_mem_type_to_ioreq_server {
>>>>        ioservid_t id;      /* IN - ioreq server id */
>>>>        uint16_t type;      /* IN - memory type */
>>>>        uint32_t flags;     /* IN - types of accesses to be forwarded to the
>>>>                               ioreq server. flags with 0 means to unmap the
>>>>                               ioreq server */
>>>>
>>>>        uint64_t opaque;    /* only used for hypercall continuation, should
>>>>                               be set to zero by the caller */
>>>> };
>>> Yes, with the field marked IN OUT and "should" replaced by "has to".
>> Got it. BTW, I can define this opaque field in patch 2/5 - the
>> introduction of this dm_op,
>> or add it in this patch 5/5 when we use it in the hypercall
>> continuation. Which one do
>> you incline?
> I'd prefer if you added it right away, i.e. in patch 2.

Got it. Thank you, Jan. :)

Yu

> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel