On 6/14/2016 6:04 PM, Jan Beulich wrote:
On 19.05.16 at 11:05, <yu.c.zh...@linux.intel.com> wrote:
@@ -5507,6 +5507,8 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
get_gfn_query_unlocked(d, a.pfn, &t);
if ( p2m_is_mmio(t) )
a.mem_type = HVMMEM_mmio_dm;
+ else if ( t == p2m_ioreq_server )
+ a.mem_type = HVMMEM_ioreq_server;
else if ( p2m_is_readonly(t) )
a.mem_type = HVMMEM_ram_ro;
else if ( p2m_is_ram(t) )
I can see this being suitable to be done here, but ...
@@ -5537,7 +5539,8 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
[HVMMEM_ram_rw] = p2m_ram_rw,
[HVMMEM_ram_ro] = p2m_ram_ro,
[HVMMEM_mmio_dm] = p2m_mmio_dm,
- [HVMMEM_unused] = p2m_invalid
+ [HVMMEM_unused] = p2m_invalid,
+ [HVMMEM_ioreq_server] = p2m_ioreq_server
};
if ( copy_from_guest(&a, arg, 1) )
... how can this be correct without actual handling having got added?
IOW doesn't at least this change belong into a later patch?
Thanks for your comments. :)
Well, although the new handling logic is in the 3rd patch, we still have
the old handling code.
Without the other patches, a developer can still use HVMMEM_ioreq_server
to write-protect
some guest ram pages, and try to handle the write operations on these
pages with the old
approach - tracking these gfns insid the ioreq server's rangeset.
Thanks
Yu
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
