From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XStXs-0001uC-1O for qemu-devel@nongnu.org; Sat, 13 Sep 2014 16:03:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XStXi-0008OF-W7 for qemu-devel@nongnu.org; Sat, 13 Sep 2014 16:03:43 -0400 Received: from mail-we0-x233.google.com ([2a00:1450:400c:c03::233]:55387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XStXi-0008O3-PZ for qemu-devel@nongnu.org; Sat, 13 Sep 2014 16:03:34 -0400 Received: by mail-we0-f179.google.com with SMTP id u56so2232059wes.10 for ; Sat, 13 Sep 2014 13:03:33 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5414A310.6000604@redhat.com> Date: Sat, 13 Sep 2014 22:03:28 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1410626712-3683-1-git-send-email-rth@twiddle.net> In-Reply-To: <1410626712-3683-1-git-send-email-rth@twiddle.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 00/23] qom hooks to clean up cpu_exec List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, afaerber@suse.de, aliguori@amazon.com Il 13/09/2014 18:44, Richard Henderson ha scritto: > > After the 23 patches, there's one (interesting) ifdef left. > That is, i386 redefining CPU_INTERRUPT_RESET as CPU_INTERRUPT_INIT > for its own purposes. I'm not sure why all that couldn't be done > under whatever hooks cpu_reset allows. There are two reasons. One is because INIT is intentionally weaker than RESET. For example, it doesn't clear many MSRs and the FPU state. The second is because INIT can be intercepted by the virtual machine monitor if SVM is enabled (KVM doesn't use it, but it is useful for example when the virtual machine monitor is letting the virtual machine use the hardware APIC). The latter could well happen on more targets than just x86, so perhaps we can have a reset_interrupt method that defaults to reset and is overridden by x86? > Failing that, we might be > able to redefine C_I_I as a new CPU_INTERRUPT_TGT_INT_3 bit. That would break migration, though admittedly only in a somewhat remote case. Paolo