[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] icount: fix cpu_restore_state_from_tb for non-t

From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH] icount: fix cpu_restore_state_from_tb for non-tb-exit cases
Date: Tue, 10 Apr 2018 10:51:36 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 04/09/2018 07:13 PM, Pavel Dovgalyuk wrote:
> In icount mode instructions, that access io memory spaces in the middle
> of the translation blocks, invoke TB recompilation.
> After recompilation such instructions become last in the TB and are
> allowed to access io memory spaces.
> When the code includes instruction like i386 'xchg eax, 0xffffd080'
> which accesses APIC, QEMU goes into the infinite loop of the recompilation.
> This instruction includes two memory accesses - one read and one write.
> After first access APIC calls cpu_report_tpr_access, which restores
> the CPU state to get the current eip. But cpu_restore_state_from_tb
> resets cpu->can_do_io flag and makes second memory access invalid.
> Therefore second memory access causes a recompilation of the block.
> Then these operations repeat again and again.
> This patch moves resetting cpu->can_do_io flag from cpu_restore_state_from_tb
> to cpu_loop_exit* functions. It also adds a parameter for cpu_restore_state*()
> which controls restoring icount. There is no need in restoring icount,
> when we only query CPU state without breaking the TB. Restoring it in such
> cases leads to the incorrect flow of the virtual time.
> In most cases new parameter is true (icount should be recalculated).
> But there are two cases in i386 and openrisc when the CPU state is only
> queued without the need to break the TB. This patch fixes both
> of these cases.
> Signed-off-by: Pavel Dovgalyuk <address@hidden>
> ---

Thanks for the patch and the detailed description.  I've applied this (with
some editing of the english in the description) to my tcg branch for 2.12.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]