>>> On 02.04.17 at 14:24, <yu.c.zh...@linux.intel.com> wrote: > Previously, p2m_ioreq_server is used to write-protect guest ram > pages, which are tracked with ioreq server's rangeset. However, > number of ram pages to be tracked may exceed the upper limit of > rangeset. > > Now, a new DMOP - XEN_DMOP_map_mem_type_to_ioreq_server, is added > to let one ioreq server claim/disclaim its responsibility for the > handling of guest pages with p2m type p2m_ioreq_server. Users of > this DMOP can specify which kind of operation is supposed to be > emulated in a parameter named flags. Currently, this DMOP only > support the emulation of write operations. And it can be further > extended to support the emulation of read ones if an ioreq server > has such requirement in the future. > > For now, we only support one ioreq server for this p2m type, so > once an ioreq server has claimed its ownership, subsequent calls > of the XEN_DMOP_map_mem_type_to_ioreq_server will fail. Users can > also disclaim the ownership of guest ram pages with p2m_ioreq_server, > by triggering this new DMOP, with ioreq server id set to the current > owner's and flags parameter set to 0. > > Note: > a> both XEN_DMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server > are only supported for HVMs with HAP enabled. > > b> only after one ioreq server claims its ownership of p2m_ioreq_server, > will the p2m type change to p2m_ioreq_server be allowed. > > c> this patch shall be accepted together with the following ones in > this series.
Fur the future: This last note doesn't really belong here, but after the first --- separator, as there's no value having this in git. > Signed-off-by: Paul Durrant <paul.durr...@citrix.com> > Signed-off-by: Yu Zhang <yu.c.zh...@linux.intel.com> > Acked-by: Tim Deegan <t...@xen.org> Reviewed-by: Jan Beulich <jbeul...@suse.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
