qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

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