On 3/14/2017 6:51 PM, Jan Beulich wrote:
On 14.03.17 at 08:42, <yu.c.zh...@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
