From: Jason Wang <jasowang@redhat.com>
To: qemu-devel@nongnu.org, richard.henderson@linaro.org,
peter.maydell@linaro.org
Cc: Akihiko Odaki <akihiko.odaki@daynix.com>,
Andrew Melnychenko <andrew@daynix.com>,
Jason Wang <jasowang@redhat.com>
Subject: [PULL 14/15] e1000e: Add ICR clearing by corresponding IMS bit
Date: Fri, 7 Jul 2023 05:06:27 -0400 [thread overview]
Message-ID: <20230707090628.2210346-15-jasowang@redhat.com> (raw)
In-Reply-To: <20230707090628.2210346-1-jasowang@redhat.com>
From: Akihiko Odaki <akihiko.odaki@daynix.com>
The datasheet does not say what happens when interrupt was asserted
(ICR.INT_ASSERT=1) and auto mask is *not* active.
However, section of 13.3.27 the PCIe* GbE Controllers Open Source
Software Developer’s Manual, which were written for older devices,
namely 631xESB/632xESB, 82563EB/82564EB, 82571EB/82572EI &
82573E/82573V/82573L, does say:
> If IMS = 0b, then the ICR register is always clear-on-read. If IMS is
> not 0b, but some ICR bit is set where the corresponding IMS bit is not
> set, then a read does not clear the ICR register. For example, if
> IMS = 10101010b and ICR = 01010101b, then a read to the ICR register
> does not clear it. If IMS = 10101010b and ICR = 0101011b, then a read
> to the ICR register clears it entirely (ICR.INT_ASSERTED = 1b).
Linux does no longer activate auto mask since commit
0a8047ac68e50e4ccbadcfc6b6b070805b976885 and the real hardware clears
ICR even in such a case so we also should do so.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1707441
Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
hw/net/e1000e_core.c | 38 ++++++++++++++++++++++++++++++++------
hw/net/trace-events | 1 +
2 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index 9f185d0..f8aeafa 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -2604,12 +2604,38 @@ e1000e_mac_icr_read(E1000ECore *core, int index)
e1000e_lower_interrupts(core, ICR, 0xffffffff);
}
- if ((core->mac[ICR] & E1000_ICR_ASSERTED) &&
- (core->mac[CTRL_EXT] & E1000_CTRL_EXT_IAME)) {
- trace_e1000e_irq_icr_clear_iame();
- e1000e_lower_interrupts(core, ICR, 0xffffffff);
- trace_e1000e_irq_icr_process_iame();
- e1000e_lower_interrupts(core, IMS, core->mac[IAM]);
+ if (core->mac[ICR] & E1000_ICR_ASSERTED) {
+ if (core->mac[CTRL_EXT] & E1000_CTRL_EXT_IAME) {
+ trace_e1000e_irq_icr_clear_iame();
+ e1000e_lower_interrupts(core, ICR, 0xffffffff);
+ trace_e1000e_irq_icr_process_iame();
+ e1000e_lower_interrupts(core, IMS, core->mac[IAM]);
+ }
+
+ /*
+ * The datasheet does not say what happens when interrupt was asserted
+ * (ICR.INT_ASSERT=1) and auto mask is *not* active.
+ * However, section of 13.3.27 the PCIe* GbE Controllers Open Source
+ * Software Developer’s Manual, which were written for older devices,
+ * namely 631xESB/632xESB, 82563EB/82564EB, 82571EB/82572EI &
+ * 82573E/82573V/82573L, does say:
+ * > If IMS = 0b, then the ICR register is always clear-on-read. If IMS
+ * > is not 0b, but some ICR bit is set where the corresponding IMS bit
+ * > is not set, then a read does not clear the ICR register. For
+ * > example, if IMS = 10101010b and ICR = 01010101b, then a read to the
+ * > ICR register does not clear it. If IMS = 10101010b and
+ * > ICR = 0101011b, then a read to the ICR register clears it entirely
+ * > (ICR.INT_ASSERTED = 1b).
+ *
+ * Linux does no longer activate auto mask since commit
+ * 0a8047ac68e50e4ccbadcfc6b6b070805b976885 and the real hardware
+ * clears ICR even in such a case so we also should do so.
+ */
+ if (core->mac[ICR] & core->mac[IMS]) {
+ trace_e1000e_irq_icr_clear_icr_bit_ims(core->mac[ICR],
+ core->mac[IMS]);
+ e1000e_lower_interrupts(core, ICR, 0xffffffff);
+ }
}
return ret;
diff --git a/hw/net/trace-events b/hw/net/trace-events
index e4a98b2..3eeacc5 100644
--- a/hw/net/trace-events
+++ b/hw/net/trace-events
@@ -217,6 +217,7 @@ e1000e_irq_read_ims(uint32_t ims) "Current IMS: 0x%x"
e1000e_irq_icr_clear_nonmsix_icr_read(void) "Clearing ICR on read due to non MSI-X int"
e1000e_irq_icr_clear_zero_ims(void) "Clearing ICR on read due to zero IMS"
e1000e_irq_icr_clear_iame(void) "Clearing ICR on read due to IAME"
+e1000e_irq_icr_clear_icr_bit_ims(uint32_t icr, uint32_t ims) "Clearing ICR on read due corresponding IMS bit: 0x%x & 0x%x"
e1000e_irq_iam_clear_eiame(uint32_t iam, uint32_t cause) "Clearing IMS due to EIAME, IAM: 0x%X, cause: 0x%X"
e1000e_irq_icr_clear_eiac(uint32_t icr, uint32_t eiac) "Clearing ICR bits due to EIAC, ICR: 0x%X, EIAC: 0x%X"
e1000e_irq_ims_clear_set_imc(uint32_t val) "Clearing IMS bits due to IMC write 0x%x"
--
2.7.4
next prev parent reply other threads:[~2023-07-07 9:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-07 9:06 [PULL 00/15] Net patches Jason Wang
2023-07-07 9:06 ` [PULL 01/15] virtio-net: correctly report maximum tx_queue_size value Jason Wang
2023-07-07 9:06 ` [PULL 02/15] hw/net: e1000: Remove the logic of padding short frames in the receive path Jason Wang
2023-07-07 9:06 ` [PULL 03/15] hw/net: vmxnet3: " Jason Wang
2023-07-07 9:06 ` [PULL 04/15] hw/net: i82596: " Jason Wang
2023-07-07 9:06 ` [PULL 05/15] hw/net: ne2000: " Jason Wang
2023-07-07 9:06 ` [PULL 06/15] hw/net: pcnet: " Jason Wang
2023-07-07 9:06 ` [PULL 07/15] hw/net: rtl8139: " Jason Wang
2023-07-07 9:06 ` [PULL 08/15] hw/net: sungem: " Jason Wang
2023-07-07 9:06 ` [PULL 09/15] hw/net: sunhme: " Jason Wang
2023-07-07 9:06 ` [PULL 10/15] hw/net: ftgmac100: Drop the small packet check " Jason Wang
2023-07-07 9:06 ` [PULL 11/15] net: socket: prepare to cleanup net_init_socket() Jason Wang
2023-07-07 9:06 ` [PULL 12/15] net: socket: move fd type checking to its own function Jason Wang
2023-07-07 9:06 ` [PULL 13/15] net: socket: remove net_init_socket() Jason Wang
2023-07-07 9:06 ` Jason Wang [this message]
2023-07-07 9:06 ` [PULL 15/15] igb: Remove obsolete workaround for Windows Jason Wang
2023-07-07 19:20 ` [PULL 00/15] Net patches Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230707090628.2210346-15-jasowang@redhat.com \
--to=jasowang@redhat.com \
--cc=akihiko.odaki@daynix.com \
--cc=andrew@daynix.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).