qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] e1000e: Added ICR clearing by corresponding IMS bit.
@ 2021-08-18 18:09 Andrew Melnychenko
       [not found] ` <CABcq3pHWydBROkHHngqO6n8D3ELdbv0eEuGynBpdfHi7tqHxcA@mail.gmail.com>
  0 siblings, 1 reply; 6+ messages in thread
From: Andrew Melnychenko @ 2021-08-18 18:09 UTC (permalink / raw)
  To: dmitry.fleytman, jasowang; +Cc: qemu-devel

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1707441

The issue is in LSC clearing. So, after "link up"(during initialization),
the next LSC event is masked and can't be processed.
Technically, the event should be 'cleared' during ICR read.
On Windows guest, everything works well, mostly because of
different interrupt routines(ICR clears during register write).
So, added ICR clearing during reading, according to the note by
section 13.3.27 of the 8257X developers manual.

Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
---
 hw/net/e1000e_core.c | 10 ++++++++++
 hw/net/trace-events  |  1 +
 2 files changed, 11 insertions(+)

diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index b75f2ab8fc..288897a975 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -2617,6 +2617,16 @@ e1000e_mac_icr_read(E1000ECore *core, int index)
         e1000e_clear_ims_bits(core, core->mac[IAM]);
     }
 
+    /*
+     * PCIe* GbE Controllers Open Source Software Developer's Manual
+     * 13.3.27 Interrupt Cause Read Register
+     */
+    if ((core->mac[ICR] & E1000_ICR_ASSERTED) &&
+        (core->mac[ICR] & core->mac[IMS])) {
+        trace_e1000e_irq_icr_clear_icr_bit_ims(core->mac[ICR], core->mac[IMS]);
+        core->mac[ICR] = 0;
+    }
+
     trace_e1000e_irq_icr_read_exit(core->mac[ICR]);
     e1000e_update_interrupt_state(core);
     return ret;
diff --git a/hw/net/trace-events b/hw/net/trace-events
index c28b91ee1a..15fd09aa1c 100644
--- a/hw/net/trace-events
+++ b/hw/net/trace-events
@@ -225,6 +225,7 @@ e1000e_irq_icr_read_entry(uint32_t icr) "Starting ICR read. Current ICR: 0x%x"
 e1000e_irq_icr_read_exit(uint32_t icr) "Ending ICR read. Current ICR: 0x%x"
 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.31.1



^ permalink raw reply related	[flat|nested] 6+ messages in thread
* [PATCH] e1000e: Added ICR clearing by corresponding IMS bit.
@ 2020-04-27 15:21 andrew
  2020-04-27 17:53 ` no-reply
  2020-04-27 18:09 ` no-reply
  0 siblings, 2 replies; 6+ messages in thread
From: andrew @ 2020-04-27 15:21 UTC (permalink / raw)
  To: qemu-devel; +Cc: jasowang, dmitry.fleytman

From: Andrew Melnychenko <andrew@daynix.com>

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1707441
Added ICR clearing if there is IMS bit - according to the note by
section 13.3.27 of the 8257X developers manual.

Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
---
 hw/net/e1000e_core.c | 9 +++++++++
 hw/net/trace-events  | 1 +
 2 files changed, 10 insertions(+)

diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index d5676871fa..8878b7ef00 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -2624,6 +2624,15 @@ e1000e_mac_icr_read(E1000ECore *core, int index)
         e1000e_clear_ims_bits(core, core->mac[IAM]);
     }
 
+    /*
+     * PCIe* GbE Controllers Open Source Software Developer’s Manual
+     * 13.3.27 Interrupt Cause Read Register
+     */
+    if (core->mac[ICR] & core->mac[IMS]) {
+        trace_e1000e_irq_icr_clear_icr_bit_ims(core->mac[ICR], core->mac[IMS]);
+        core->mac[ICR] = 0;
+    }
+
     trace_e1000e_irq_icr_read_exit(core->mac[ICR]);
     e1000e_update_interrupt_state(core);
     return ret;
diff --git a/hw/net/trace-events b/hw/net/trace-events
index e18f883cfd..46e40fcfa9 100644
--- a/hw/net/trace-events
+++ b/hw/net/trace-events
@@ -237,6 +237,7 @@ e1000e_irq_icr_read_entry(uint32_t icr) "Starting ICR read. Current ICR: 0x%x"
 e1000e_irq_icr_read_exit(uint32_t icr) "Ending ICR read. Current ICR: 0x%x"
 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.24.1



^ permalink raw reply related	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-10-28  3:26 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-08-18 18:09 [PATCH] e1000e: Added ICR clearing by corresponding IMS bit Andrew Melnychenko
     [not found] ` <CABcq3pHWydBROkHHngqO6n8D3ELdbv0eEuGynBpdfHi7tqHxcA@mail.gmail.com>
     [not found]   ` <CACGkMEv5=gd07Qtf8N0bY66d4ZtLNytzei=yHfC_=D_X_43oyQ@mail.gmail.com>
     [not found]     ` <CABcq3pHekALcR_vh9nayoyxANBh87Q53vs89eAj9unZQUXBnDA@mail.gmail.com>
     [not found]       ` <CACGkMEtCd1A4tTnj_LNHX0zY3ADdopM2AvFchuj15=1v8sKKzg@mail.gmail.com>
2021-10-27 10:57         ` Andrew Melnichenko
2021-10-28  3:15           ` Jason Wang
  -- strict thread matches above, loose matches on Subject: below --
2020-04-27 15:21 andrew
2020-04-27 17:53 ` no-reply
2020-04-27 18:09 ` no-reply

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).