[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 3/14/2017 6:51 PM, Jan Beulich wrote: 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". 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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |