From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFCE4C4646B for ; Tue, 25 Jun 2019 02:30:02 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8272C20644 for ; Tue, 25 Jun 2019 02:30:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8272C20644 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:55952 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hfbDd-0000a7-J8 for qemu-devel@archiver.kernel.org; Mon, 24 Jun 2019 22:30:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54549) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hfbD8-00008S-Qh for qemu-devel@nongnu.org; Mon, 24 Jun 2019 22:29:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hfbD7-0000wy-Sx for qemu-devel@nongnu.org; Mon, 24 Jun 2019 22:29:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56018) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hfbD7-0000w4-N6 for qemu-devel@nongnu.org; Mon, 24 Jun 2019 22:29:29 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DD5B93086202; Tue, 25 Jun 2019 02:29:27 +0000 (UTC) Received: from xz-x1 (unknown [10.66.60.185]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B1B0E60BE2; Tue, 25 Jun 2019 02:29:22 +0000 (UTC) Date: Tue, 25 Jun 2019 10:29:20 +0800 From: Peter Xu To: Li Qiang Message-ID: <20190625022920.GA9750@xz-x1> References: <20190624151635.22494-1-liq3ea@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190624151635.22494-1-liq3ea@163.com> User-Agent: Mutt/1.11.4 (2019-03-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Tue, 25 Jun 2019 02:29:27 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH] ioapic: clear irq_eoi when updating the ioapic redirect table entry X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: pbonzini@redhat.com, liq3ea@gmail.com, qemu-devel@nongnu.org, mst@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, Jun 24, 2019 at 08:16:35AM -0700, Li Qiang wrote: > irq_eoi is used to count the number of irq injected during eoi > broadcast. It should be set to 0 when updating the ioapic's redirect > table entry. > > Suggested-by: Peter Xu > Signed-off-by: Li Qiang > --- > hw/intc/ioapic.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c > index 7074489fdf..db9e518602 100644 > --- a/hw/intc/ioapic.c > +++ b/hw/intc/ioapic.c > @@ -380,6 +380,7 @@ ioapic_mem_write(void *opaque, hwaddr addr, uint64_t val, > /* restore RO bits */ > s->ioredtbl[index] &= IOAPIC_RW_BITS; > s->ioredtbl[index] |= ro_bits; > + s->irq_eoi[index] = 0; It'll be cleared for twice for each ioapic entry because it only supports 32bit write to these registers. Though it seems fine, e.g., when the guest only want to update the vector info we should still clear it: Reviewed-by: Peter Xu > ioapic_fix_edge_remote_irr(&s->ioredtbl[index]); > ioapic_service(s); > } > -- > 2.17.1 > > Regards, -- Peter Xu