Re: [PATCH 2/3] i386: hvf: In kick_vcpu use hv_vcpu_interrupt to force exit

[Roman Bolshakov <roman@roolebo.dev>]

On Fri, Oct 20, 2023 at 05:12:13PM +0200, Phil Dennis-Jordan wrote:
> Hi Roman, hi Paolo,
> 

Hi Phil,

Pardon for not responding earlier. I was travelling the last three weeks.

I appreciate the time you spent on the rebase. I have compiled it and
observed the same issue with SVGA like with your third patch.

> 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.
> 

That sounds awesome, I think you have tracked it down correctly. I have
also looked at SVGA code and the only idea I had is dirty tracking is
somehow not working properly.

I observed similar issue when tried to add GDB stub for x86 hvf. The
changes from GDB stub produced no apparent effect on the guest -
breakpoints were there, in the memory but did not stop the guest and so
on. I got lost why it didn't work back then.

> 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.

Best regards,
Roman