> 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.
>
Sounds good, have you got anything to test or review? Meanwhile, I'll
review the pending patches you sent.
Sorry, I've likewise been busy with other things the last 2-3 weeks.
As far as I'm aware, we don't actually know 100% for certain if there's a race condition when using hv_vcpu_interrupt(), right? (As I mentioned, the patches with hv_vcpu_run_until and a hv_vcpu_interrupt-only kick have been running without issue for months on dozens to hundreds of VMs.) So before we add the complexity of the hybrid hv_vcpu_interrupt & signal-based kick to the codebase, I'd like to test out hv_vcpu_interrupt's behaviour in isolation and actually force the edge cases we're worried about. But yeah, I haven't got around to doing that yet. :-) I'm hoping to take a crack at it later this week or next week, probably using
https://github.com/mist64/hvdos as a starting point.
Thanks for reviewing and testing the first set of patches!
Phil