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 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?

>> If so, is there any approach in hypervisor to differentiate the first
>> call from the continued
>> hypercall? Do we need some form of check on this opaque?
> I don't see a need (other than - of course - the obvious upper
> bound imposed here), due to ...
>
>> And yes, not
>> playing by this
>> will only harm the guest the device model controls.
> ... this.

OK. I'm fine with this too. :-)

Thanks
Yu

> Jan
>
>


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