From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: [Qemu-devel] [question] e1000 interrupt storm happenedbecauseofitscorrespondingioapic->irr bit always set Date: Fri, 29 Aug 2014 12:28:06 +0800 Message-ID: <54000156.9050401@redhat.com> References: <201408231836387399956@sangfor.com>, <53FAA874.70703@redhat.com>, <201408251517235889695@sangfor.com>, <53FAE5EB.8080809@redhat.com>, <201408261728240882530@sangfor.com>, <53FD681D.7070602@redhat.com>, <201408271731497879013@sangfor.com>, <201408282055150251894@sangfor.com> <201408291114352277288@sangfor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: "Zhang, Yang Z" , Zhang Haoyu , qemu-devel , kvm , Gleb Natapov , "Michael S.Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:64702 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751709AbaH2E2X (ORCPT ); Fri, 29 Aug 2014 00:28:23 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 08/29/2014 12:07 PM, Zhang, Yang Z wrote: > Zhang Haoyu wrote on 2014-08-29: >> > Hi, Yang, Gleb, Michael, >> > Could you help review below patch please? > I don't quite understand the background. Why ioacpi->irr is setting before EOI? It should be driver's responsibility to clear the interrupt before issuing EOI. > This may happen when a interrupt was injected to guest when its irq handler (driver) was not registered. So irr was still set even during EOI broadcast, and then this irq will be injected to guest immediately. This may cause a dead loop for guest who does not have the ability to detect and disable interrupt storm. This may be a bug of device model, but we want to know in real cpu, is there a small time gap between the finish of EOI broadcast and the interrupt raised by EOI? If yes, looks like KVM should emulate this behaviour? Thanks