From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTCcY-0006kI-9A for qemu-devel@nongnu.org; Tue, 30 Oct 2012 10:16:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTCcO-00023g-8q for qemu-devel@nongnu.org; Tue, 30 Oct 2012 10:16:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTCcO-00023Y-12 for qemu-devel@nongnu.org; Tue, 30 Oct 2012 10:16:36 -0400 Message-ID: <508FE140.2000302@redhat.com> Date: Tue, 30 Oct 2012 15:16:32 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1351599394-24876-1-git-send-email-pbonzini@redhat.com> <1351599394-24876-4-git-send-email-pbonzini@redhat.com> <508FCA33.5030309@redhat.com> In-Reply-To: <508FCA33.5030309@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] apic: always update the in-kernel status after loading List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: jan.kiszka@siemens.com, mtosatti@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org Il 30/10/2012 13:38, Avi Kivity ha scritto: > On 10/30/2012 02:16 PM, Paolo Bonzini wrote: >> The LAPIC is loaded separately from the rest of the VCPU state. Thus, >> when restoring the CPU the dummy post-reset state is passed to the >> in-kernel APIC. >> >> This can cause MSI injection to fail if attempted during the restore of >> another device, because the LAPIC believes it's not enabled. >> >> Signed-off-by: Paolo Bonzini >> --- >> hw/apic_common.c | 1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/hw/apic_common.c b/hw/apic_common.c >> index f373ba8..1ef52b2 100644 >> --- a/hw/apic_common.c >> +++ b/hw/apic_common.c >> @@ -362,6 +362,7 @@ static int apic_dispatch_post_load(void *opaque, int version_id) >> if (info->post_load) { >> info->post_load(s); >> } >> + cpu_put_apic_state(DEVICE(s)); >> return 0; >> } > > Aren't we still dependent on the order of processing? If the APIC is > restored after the device, won't we get the same problem? Strictly speaking yes, but CPUs and APICs are always the first devices to be saved. Paolo