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

[Alexander Graf <agraf@suse.de>]

On 02.07.14 11:02, Gabriel L. Somlo wrote:
> On Mon, Jun 30, 2014 at 08:21:43PM +0200, Alexander Graf wrote:
>>
>>> Am 30.06.2014 um 19:55 schrieb "Michael S. Tsirkin" <mst@redhat.com>:
>>>
>>>> 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 <somlo@cmu.edu>
>>>> ---
>>>>
>>>> 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...

Yeah, maybe the interrupt is masked and doesn't get delivered properly? 
See if you can trace when the e1000 emulation starts kicking an 
interrupt and when the guest tries to fetch it (there should be an ack 
register for IRQs somewhere).

If we kick it but the guest doesn't react, the problem is further down - 
check whether the IRQ ever got injected into the guest with trace points.

If we don't kick it, we mask it somewhere in the e1000 emulation and 
need to make sure we do kick once we unmask :). I don't know whether the 
LSC mask is the only one involved.


Alex