x86/hvm: finish IOREQs correctly on completion path
authorIgor Druzhinin <igor.druzhinin@citrix.com>
Mon, 18 Mar 2019 15:29:21 +0000 (16:29 +0100)
committerJan Beulich <jbeulich@suse.com>
Mon, 18 Mar 2019 15:29:21 +0000 (16:29 +0100)
commit522a2f3c5c89cc78c0e2b05af924b76cef7d4bff
tree922d8a3266939259997e4c2c96445a70171c1c7c
parent2d527ba310dc6695bba2df118ff9e053f7e40c82
x86/hvm: finish IOREQs correctly on completion path

Since the introduction of linear_{read,write}() helpers in 3bdec530a5
(x86/HVM: split page straddling emulated accesses in more cases) the
completion path for IOREQs has been broken: if there is an IOREQ in
progress but hvm_copy_{to,from}_guest_linear() returns HVMTRANS_okay
(e.g. when P2M type of source/destination has been changed by IOREQ
handler) the execution will never re-enter hvmemul_do_io() where
IOREQs are completed. This usually results in a domain crash upon
the execution of the next IOREQ entering hvmemul_do_io() and finding
the remnants of the previous IOREQ in the state machine.

This particular issue has been discovered in relation to p2m_ioreq_server
type where an emulator changed the memory type between p2m_ioreq_server
and p2m_ram_rw in process of responding to IOREQ which made
hvm_copy_..() to behave differently on the way back.

Fix it for now by checking if IOREQ completion is required (which
can be identified by querying MMIO cache) before trying to finish
a memory access immediately through hvm_copy_..(), re-enter
hvmemul_do_io() otherwise. This change alone only addresses IOREQ
completion issue for P2M type changing from MMIO to RAM in the
middle of emulation but leaves a case where new IOREQs might be
introduced by P2M changes from RAM to MMIO (which is less likely
to find in practice) that requires more substantial changes in
MMIO emulation code.

Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
xen/arch/x86/hvm/emulate.c