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?