On Mon, 2015-09-21 at 22:54 +0200, Francois Romieu wrote: > David Woodhouse <dw...@infradead.org> : > [...] > > I'm actually having second thoughts about this one since realising that > > QEMU doesn't implement it correctly. The workaround isn't *that* horrid > > but it's not clear it's enough of a performance win — or whether it's > > entirely necessary for catching my TX stall. > > It don't indulge in this kind of fetish but I'm fine with people who want > to play with QEMU 8139cp emulation where they could use virtio. They should > imvho realize that it's their job to fix QEMU 8139cp emulation, not the > other way around.
Oh, I'll fix the QEMU emulation (but not this week; updating my router has taken long enough already and I have Real Work™ to do). But those fixes will take time to propagate to actual users. I'm not sure it's so reasonable to knowingly break the 8139cp driver for all currently-released versions of QEMU. It wouldn't surprise me to find that QEMU probably accounts for the *majority* of 8139cp use on modern Linux kernels. I've had to fix regressions which *only* fail on real hardware, and were *only* tested on QEMU :) > Please keep things sane (*cough*) and avoid the qemu workaround. I don't even know that I need it. As you saw in my last WIP patch for catching the TX stall, I was just checking for TxEmpty without TxDone. An earlier iteration had actually remembered the last slot that was already present when we prodded the TxPoll, and would warn on getting a TxEmpty interrupt while that slot was still owned by the hardware. But that has the *same* false positives, only *after* the initial stall, that my current version has. So I'm just not sure I care about eliminating the gratuitous TxPoll writes. It's not as if we even wait for them. It's an MMIO write which can complete later. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
