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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

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
reality. That's why not synchronizing properly is "expensive" (or broken
IOW).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]