Re: [Qemu-devel] [RFC PATCH v1 2/2] e1000: adjust initial autoneg timing (for piix/osx)

[Gabriel L. Somlo]

On Mon, Jun 30, 2014 at 08:21:43PM +0200, Alexander Graf wrote:
> 
> 
> > Am 30.06.2014 um 19:55 schrieb "Michael S. Tsirkin" <address@hidden>:
> > 
> >> On Mon, Jun 30, 2014 at 12:55:50PM -0400, Gabriel L. Somlo wrote:
> >> When running on PIIX (as opposed to q35), the stock OS X e1000
> >> driver (AppleIntel8254XEthernet.kext) takes longer to load and
> >> activete, and will "miss" the link status change interrupt
> >> injected when the emulated "hardware" autonegotiation completes
> >> (see commit 39bb8ee737595e9b264d075dfcd7d86f4d3f1133).
> >> 
> >> This patch extends the delay of the autonetotiation timer set up
> >> during set_phy_ctrl() to a value just large enough to work with
> >> the OS X driver.
> >> 
> >> Signed-off-by: Gabriel Somlo <address@hidden>
> >> ---
> >> 
> >> So, the loading OS X driver must take longer between its last
> >> write to the PHY_CTRL register and the time it starts looking
> >> for LSC interrupts, because at delay==500 it obviously misses
> >> the relevant interrupt. Making this 5500 (actually anything
> >> larger than 5300, but there's a bit of variation across OS X
> >> versions, so I rounded up a bit) has the timer fire after
> >> enough time has passed that the driver knows what to do when
> >> the interrupt from the network card fires...
> >> 
> >> Thanks,
> >>  Gabriel
> >> 
> >> hw/net/e1000.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> >> index 2376910..2300477 100644
> >> --- a/hw/net/e1000.c
> >> +++ b/hw/net/e1000.c
> >> @@ -209,7 +209,7 @@ set_phy_ctrl(E1000State *s, int index, uint16_t val)
> >>         e1000_link_down(s);
> >>         DBGOUT(PHY, "Start link auto negotiation\n");
> >>         timer_mod(s->autoneg_timer,
> >> -                  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 500);
> >> +                  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 5500);
> >>     }
> >> }
> > 
> > 
> > Besides being a bit hacky, it actually has a decent chance
> > to delay boot for guests. 500ms is probably the max we
> > can reasonably tolerate, even that is a bit high.
> 
> Are you sure there's not just simply some irq unmasking event after 5500ms we 
> don't handle properly?

I poked around a bit, and the e1000 interrupt mask register is NOT the
problem (the LSC mask bit is clear at all times). If anything, maybe
the PIIX southbridge (or something further up "north") is masking PCI
interrupts (at least from e1000) until roughly 5500 ms into the boot
process ? Any ideas on how I could go about verifying this (without
access to the guest source, obviously :) ) would be very helpful...

Thanks,
--Gabriel