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

Reply via email to