[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] p2m type change confusing emulator

  • To: "xen-devel" <xen-devel@xxxxxxxxxxxxx>
  • From: "Jan Beulich" <JBeulich@xxxxxxxx>
  • Date: Mon, 02 Jul 2012 15:42:31 +0100
  • Delivery-date: Mon, 02 Jul 2012 14:41:55 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

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

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,

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.