Re: [PATCH] Don't call cpu_synchronize_state() in apic_init_reset()

[Jan Kiszka <jan.kiszka@siemens.com>]

Gleb Natapov wrote:
> On Thu, Sep 24, 2009 at 10:59:46AM +0200, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> On Thu, Sep 24, 2009 at 10:15:15AM +0200, Jan Kiszka wrote:
>>>> Gleb Natapov wrote:
>>>>> On Thu, Sep 24, 2009 at 10:53:59AM +0300, Avi Kivity wrote:
>>>>>> On 09/23/2009 06:45 PM, Jan Kiszka wrote:
>>>>>>>> Functions calling each other in the same subsystem can rely on callers
>>>>>>>> calling cpu_synchronize_state().  Across subsystems, that's another
>>>>>>>> matter, exported functions should try not to rely on implementation
>>>>>>>> details of their callers.
>>>>>>>>
>>>>>>>> (You might argue that the apic is not separate subsystem wrt an x86 cpu,
>>>>>>>> and I'm not sure I have a counterargument)
>>>>>>>>
>>>>>>> I do accept this argument. It's just that my feeling is that we are
>>>>>>> lacking proper review of the required call sites of cpu_sychronize_state
>>>>>>> and rather put it where some regression popped up (and that only in
>>>>>>> qemu-kvm...).
>>>>>> That's life...
>>>>>>
>>>>>>> The new rule is: Synchronize the states before accessing registers (or
>>>>>>> in-kernel devices) the first time after a vmexit to user space.
>>>>>> No, the rule is: synchronize state before accessing registers.
>>>>>> Extra synchronization is cheap, while missing synchronization is
>>>>>> very expensive.
>>>>>>
>>>>> So should we stick cpu_synchronize_state() before each register
>>>>> accesses? I think it is reasonable to omit it if all callers do it
>>>>> already.
>>>>>
>>>>>>> But,
>>>>>>> e.g., I do not see where we do this on CPU reset.
>>>>>> That's a bug.
>>>>>>
>>>>> Only if kvm support cpus without apic. Otherwise CPU is reset by 
>>>>> apic_reset() and cpu_synchronize_state() is called there.
>>>> No, that's not enough if cpu_reset() first fiddles with some registers
>>>> that may later on be overwritten on cpu_synchronize_state() with the old
>>>> in-kernel state. At least in theory, haven't checked yet what happens in
>>> Can't happen. Call chain is apic_reset() -> cpu_reset() and apic_reset()
>>> calls  cpu_synchronize_state() before calling cpu_reset().
>> And system_reset?
>>
> And system_reset calls apic_reset() if cpu has apic, cpu_reset()
> otherwise. That is why I said that the bug is only for cpus without
> apic.

Yes, I see now. Still, it's not a good reference for other archs (did
anyone already checked the situation on ppc?). Will file a patch.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux