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 <[email protected]> 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
