[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] cpu: flush TB cache when loading VMState
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH] cpu: flush TB cache when loading VMState |
Date: |
Thu, 11 Jan 2018 11:15:05 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 |
On 10/01/2018 19:32, Peter Maydell wrote:
> On 10 January 2018 at 17:49, Richard Henderson
> <address@hidden> wrote:
>> On 01/10/2018 05:48 AM, Pavel Dovgalyuk wrote:
>>> Flushing TB cache is required because TBs key in the cache may match
>>> different code which existed in the previous state.
>>>
>>> Signed-off-by: Pavel Dovgalyuk <address@hidden>
>>> Signed-off-by: Maria Klimushenkova <address@hidden>
>>> ---
>>> exec.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/exec.c b/exec.c
>>> index 4722e52..ff31e71 100644
>>> --- a/exec.c
>>> +++ b/exec.c
>>> @@ -622,6 +622,7 @@ static int cpu_common_post_load(void *opaque, int
>>> version_id)
>>> version_id is increased. */
>>> cpu->interrupt_request &= ~0x01;
>>> tlb_flush(cpu);
>>> + tb_flush(cpu);
>>
>> I'm not necessarily objecting, but what do you mean by "may match different
>> code"?
>>
>> What this patch suggests is that the inputs to the computation of TB->FLAGS
>> are
>> different for some unspecified reason. Without further explanation, to me
>> this
>> suggests a bug in vmstate save/restore.
>
> Yeah, this looks a little fishy. If there's code in the TB cache
> which would be wrong for the freshly-reset (or whatever)
> CPU after a VM state load, then it could just as easily
> be wrong for a 2nd CPU in an SMP config.
RAM contents are memcpy'd blindly during loadvm. I think that's what
requires a tb_flush.
Paolo