[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH] e1000: Delay LSC until mask is active
Date: Thu, 3 Jul 2014 23:18:15 +0300

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 <address@hidden> 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]