Hi Roman, hi Paolo, Just an update on my investigation of the hv_vcpu_run -> hv_vcpu_run_until issue. The graphical issues with the Windows XP VM appear to be caused by the dirty memory page system not working as expected. The emulated (Cirrus) VGA adapter uses dirty page tracking to perform partial screen updates, so when pages aren't marked as dirty, they don't get updated on the host console.
This got me digging into how dirty memory tracking is actually implemented in the Qemu hvf backend, and basically, it should never have worked in the first place. When we get a write fault, the code marks the *whole* 'logged' memory range as writable rather than just the page that's just been dirtied. It just so happens that hv_vcpu_run was causing EPT fault exits on those pages even after marking them writable (?), and hv_vcpu_run_until() no longer does that. So basically, this has been a Qemu bug masked by undesirable hv_vcpu_run() behaviour. I'll start putting together a fix for this. I'm also hoping to settle the hv_vcpu_interrupt() race condition question empirically - if we can avoid the complicated signal/vmexit race avoidance logic with atomic flags, that will make the code rather simpler. Phil