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? Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
