From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2nQa-0001Eq-Ki for qemu-devel@nongnu.org; Thu, 03 Jul 2014 16:16:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2nQV-0001Ek-Mu for qemu-devel@nongnu.org; Thu, 03 Jul 2014 16:16:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2nQV-0001Ec-ES for qemu-devel@nongnu.org; Thu, 03 Jul 2014 16:16:15 -0400 Date: Thu, 3 Jul 2014 23:18:15 +0300 From: "Michael S. Tsirkin" Message-ID: <20140703201815.GD29214@redhat.com> References: <1404409177-3226-1-git-send-email-agraf@suse.de> <53B59A24.5090000@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B59A24.5090000@suse.de> Subject: Re: [Qemu-devel] [PATCH] e1000: Delay LSC until mask is active List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , Gabriel Somlo , QEMU Developers , Stefan Hajnoczi , Paolo Bonzini On Thu, Jul 03, 2014 at 08:00:04PM +0200, Alexander Graf wrote: > > On 03.07.14 19:57, Peter Maydell wrote: > >On 3 July 2014 18:39, Alexander Graf wrote: > >>Mac OS X reads ICR on every interrupt. When the IRQ line is shared, this may > >>result in a race where LSC is not interpreted yet, but already gets cleared. > >> > >>The guest already has a way of telling us that it can interpret LSC events > >>though and that's via the interrupt mask register (IMS). > >> > >>So if we just leave the LSC interrupt bit pending, but invisible to the guest > >>as long as it's not ready to receive LSC interrupts, we basically defer the > >>interrupt to the earliest point in time when the guest would know how to > >>handle it. > >This would break any guests dealing with this in a polling > >mode (ie "permanently leave interrupts masked and read > >ICR periodically to find out whether anything interesting > >has happened"), right? > > If those guests would wait for a link detect event that way, yes. > > Considering all the hackery we already have about link negotiation (delay it > until a random amount of ms passed) I'd say the breakage this patch fixes is > a lot more likely than a polling guest that waits for a link based on > ICR.LSC :). > > > Alex Well that hackery was justified by the claim that real hardware behaves this way: it has a random delay since it needs a bit of time to bring the link up. What's the justification here? How come this driver works with real hardware? -- MST