Re: [Qemu-devel] e1000 autoneg timing, piix/osx

[Alexander Graf]

> Am 02.07.2014 um 23:14 schrieb "Gabriel L. Somlo" <address@hidden>:
> 
>> On Wed, Jul 02, 2014 at 11:02:30PM +0200, Alexander Graf wrote:
>> 
>>> On 02.07.14 22:49, Gabriel L. Somlo wrote:
>>> So it turns out everything I thought I knew (which was little indeed)
>>> was more or less wrong. The problem, as far as I'm observing it now,
>>> is that on PIIX, the OS X guest obsessively reads the ICR in a tight
>>> loop. It reads the injected LSC (and probably discards it) before
>>> unmasking the corresponding interrupt bit; later on, when it unmasks
>>> LSC, giving the emulated e1000 hardware a chance to raise the irq
>>> line, the actual LSC event has been flushed from the ICR, and the
>>> driver does not detect the link coming up.
>>> 
>>> [...]
>>> 
>>> Any clue as to why ICR gets read like that on PIIX, but not Q35 ?
>> 
>> Either way, why does the bit get cleared even though it hasn't been raised?
>> What does real hardware do with interrupts that have been masked?
> 
> The e1000 manual says ICR bits are cleared on read. It also says PCI
> interrupts are only generated if the corresponding bit in *both* ICR
> and IMS registers is 1. ICR bits are still cleared if read, even if
> masked and no actual interrupt is raised.
> 
>> Maybe it's using MSI on q35? :)
>> Maybe we also share the same IRQ line with another device on PIIX that gets
>> polled all the time? IDE maybe?
> 
> Even if that were the case, how come it's reading precisely our
> device's ICR register ? Isn't that too much of a coincidence ? 

When PCI devices share an irq line, the OS needs to poke all devices on that 
line to figure out which device the IRQ came from. Maybe it's reading ICR for 
that purpose?

Alex

> 
> /me goes back to reading about PIIX and ICH10 (840 pages FTW!) :)
>