On 3/13/2017 7:22 PM, Jan Beulich wrote:
On 11.03.17 at 09:42, <yu.c.zh...@linux.intel.com> wrote:
On 3/10/2017 11:33 PM, Jan Beulich wrote:
On 08.03.17 at 16:33, <yu.c.zh...@linux.intel.com> wrote:
@@ -197,6 +217,10 @@ static int hvmemul_do_io(
* - If the IOREQ_MEM_ACCESS_WRITE flag is not set, treat it
* like a normal PIO or MMIO that doesn't have an ioreq
* server (i.e., by ignoring it).
+ *
+ * - If the accesss is a read, this could be part of a
+ * read-modify-write instruction, emulate the read so that we
+ * have it.
"it" being what here? Grammatically the insn, but we don't care
about "having" the insn.
Here "have it" means " to have the value on this address copied in".
Sorry for the inaccurate comment. How about just "emulate the read first"?
Sounds okay.
@@ -226,6 +250,17 @@ static int hvmemul_do_io(
}
/*
+ * This is part of a read-modify-write instruction.
"is" or "may be"?
I believe should be "is".
It's the only scenario I can imagine when an read operation(only when
this operation is
also a write one) traps. Otherwise there shall be no VM exit.
Even with a racing update to the type?
Yes.
With patch 1/5, there shall be no racing update to the p2m type during
this process.
Besides, I believe even without patch 1/5, and we allow the racing p2m
change, it will
only happen on a p2m_ioreq_server page changed to p2m_ram_rw(in such
case it is shall
only be a write or a read-modify-write op that cause such vm exit). The
race will not
happen for a p2m_ram_rw page changed to p2m_ioreq_server, because there
shall be no
vm exit at all.
Thanks
Yu
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
