[Xen-devel] p2m type change confusing emulator

["Jan Beulich" <JBeulich@xxxxxxxx>]

In a problem report for a non-Linux HVM guest with PV drivers that
got brought to our attention, an issue in the PV driver code caused
a XENMAPSPACE_shared_info operation to be issued in a way
racing ongoing MMIO emulations on other vCPU-s targeting the
gPFN being changed.

The way MMIO emulation requiring callout into qemu currently works,
handle_mmio() would be called twice for each such operation. This
clearly assumes that both operations use consistent paths, which
is easily violated when between the two operations the p2m type
of the page operated on changes (in the case at hand, the
transition was from MMIO [not handled by any device] to RAM,
i.e. the second run through the emulator didn't even call the
MMIO related code anymore, leaving the vCPU's io_state in
HVMIO_completed instead of HVMIO_none, confusing the _next_
invocation of the emulator, and obfuscating the problem quite
significantly).

While I realize that the guest side problem makes debatable
whether the situation really needs hypervisor improvement, I'd
like cases like hot-added memory or devices to be considered
here too. In particular I wonder whether emulator state
shouldn't be preserved across the invocation of qemu, so that
the second run through it would neither risk of looking at a
different instruction, nor having the emulated instruction
access other (guest) physical memory - after all, real hardware
wouldn't decode instructions and evaluate operands more than
once either.

Thanks for any thoughts on this,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel