>>> On 11.08.16 at 10:47, <yu.c.zh...@linux.intel.com> wrote: > On 8/10/2016 6:43 PM, Yu Zhang wrote: >> For " && p2mt != p2m_ioreq_server" condition, it is just to guarantee >> that if a write >> operation is trapped, and at the same period, device model changed the >> status of >> ioreq server, it should be discarded. > > Hi Paul & Jan, any comments?
Didn't Paul's "should behave like p2m_ram_rw" reply clarify things sufficiently? >> A second thought is, I am now more worried about the " && dir == >> IOREQ_WRITE" >> condition, which we used previously to set s to NULL if it is not a >> write operation. >> However, if HVM uses a read-modify-write instruction to operate on a >> write-protected >> address, it will be treated as both read and write accesses in >> ept_handle_violation(). In >> such situation, we need to emulate the read access first(by just >> returning the value being >> fetched either in hypervisor or in device model), instead of >> discarding the read access. > > Any suggestions about this guest read-modify-write instruction situation? > Is my depiction clear? :) Well, from your earlier reply I concluded that you'd just go ahead and put this into patch form, which we'd then look at. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel