From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] Don't call cpu_synchronize_state() in apic_init_reset() Date: Fri, 25 Sep 2009 17:03:49 +0200 Message-ID: <4ABCDBD5.7040603@siemens.com> References: <1253631112-26124-3-git-send-email-gleb@redhat.com> <4AB9E3BC.7060304@redhat.com> <4ABA399F.6030003@web.de> <4ABA3C14.7080803@redhat.com> <4ABA42A1.4010904@web.de> <4ABB2597.7090107@redhat.com> <20090924080312.GB9832@redhat.com> <4ABB2A93.9040905@web.de> <20090924083054.GA14258@redhat.com> <4ABB3502.4010701@web.de> <20090924091145.GB14258@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from thoth.sbs.de ([192.35.17.2]:21734 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752750AbZIYPEA (ORCPT ); Fri, 25 Sep 2009 11:04:00 -0400 In-Reply-To: <20090924091145.GB14258@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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