Re: [Qemu-devel] [PATCH] e1000: Delay LSC until mask is active

["Michael S. Tsirkin" <mst@redhat.com>]

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 <agraf@suse.de> 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