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

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



>>> On 14.03.17 at 08:42, <yu.c.zhang@xxxxxxxxxxxxxxx> 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".

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

Jan


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

 


Rackspace

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