Re: [PATCH] e1000e: Added ICR clearing by corresponding IMS bit.
On Wed, Oct 27, 2021 at 6:57 PM Andrew Melnichenko wrote:
>
> Hi,
> Let's make things clear.
> At first, I've decided to fix the issue in the linux e1000e driver.
> (https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20200413/019497.html)
> Original driver developers suggest to fix the issue on qemu and assures that
> driver works correctly on real hw.
> I've added fix according to the note 13.3.28 of the 8257X manual
> (https://www.intel.com/content/dam/www/public/us/en/documents/manuals/pcie-gbe-controllers-open-source-manual.pdf)
> I've reference to 8257X spec which is an apparently a bit different to
> 82574l-gbe-controller-datasheet.pdf
Yes, and 82475l is the referenced model when developing e1000e
emulation code I think.
Thanks
>
>
> On Thu, Oct 21, 2021 at 5:16 AM Jason Wang wrote:
>>
>> Hi Andrew:
>>
>> On Thu, Oct 21, 2021 at 6:27 AM Andrew Melnichenko wrote:
>> >
>> > Hi,
>> > I've used this
>> > manual(https://www.intel.com/content/dam/www/public/us/en/documents/manuals/pcie-gbe-controllers-open-source-manual.pdf)
>> > It was provided by Intel when I've tried to research that bug.
>> > Although it's a bit newer manual - the article is 13.3.28.
>>
>> Note that it's not the model that e1000e tries to implement (82574L).
>> The device ID in qemu is 0x10D3 which is not listed in the above link
>> "4.7.7 Mandatory PCI Configuration Registers".
>>
>> Thanks
>>
>> >
>> >
>> > On Tue, Oct 19, 2021 at 10:56 AM Jason Wang wrote:
>> >>
>> >> On Thu, Oct 14, 2021 at 4:34 PM Andrew Melnichenko
>> >> wrote:
>> >> >
>> >> > Ping
>> >> >
>> >> > On Wed, Aug 18, 2021 at 9:10 PM Andrew Melnychenko
>> >> > wrote:
>> >> >>
>> >> >> 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
>> >> >> ---
>> >> >> 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
>> >>
>> >> Per link in the beginning of this file it should be 82574l I guess?
>> >>
>> >> If yes, I'm using revision 3.4 and it's 13.3.27 is not about ICR.
>> >>
>> >> What it said are:
>> >>
>> >> "
>> >> In MSI-X mode the bits in this register can be configured to
>> >> auto-clear when the MSI-X interrupt message is sent, in order to
>> >> minimize driver overhead, and when using MSI-X interrupt signaling. In
>> >> systems that do not support MSI-X, reading the ICR register clears
>> >> it's bits or writing 1b's clears the corresponding bits in this
>> >> 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;
>> >> >> +}
>> >>
>> >> Thanks
>> >>
>> >> >> +
>> >> >> 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_c
Re: [PATCH] e1000e: Added ICR clearing by corresponding IMS bit.
Hi,
Let's make things clear.
At first, I've decided to fix the issue in the linux e1000e driver.
(
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20200413/019497.html
)
Original driver developers suggest to fix the issue on qemu and assures
that driver works correctly on real hw.
I've added fix according to the note 13.3.28 of the 8257X manual
(
https://www.intel.com/content/dam/www/public/us/en/documents/manuals/pcie-gbe-controllers-open-source-manual.pdf
)
I've reference to 8257X spec which is an apparently a bit different to
82574l-gbe-controller-datasheet.pdf
On Thu, Oct 21, 2021 at 5:16 AM Jason Wang wrote:
> Hi Andrew:
>
> On Thu, Oct 21, 2021 at 6:27 AM Andrew Melnichenko
> wrote:
> >
> > Hi,
> > I've used this manual(
> https://www.intel.com/content/dam/www/public/us/en/documents/manuals/pcie-gbe-controllers-open-source-manual.pdf
> )
> > It was provided by Intel when I've tried to research that bug.
> > Although it's a bit newer manual - the article is 13.3.28.
>
> Note that it's not the model that e1000e tries to implement (82574L).
> The device ID in qemu is 0x10D3 which is not listed in the above link
> "4.7.7 Mandatory PCI Configuration Registers".
>
> Thanks
>
> >
> >
> > On Tue, Oct 19, 2021 at 10:56 AM Jason Wang wrote:
> >>
> >> On Thu, Oct 14, 2021 at 4:34 PM Andrew Melnichenko
> wrote:
> >> >
> >> > Ping
> >> >
> >> > On Wed, Aug 18, 2021 at 9:10 PM Andrew Melnychenko
> wrote:
> >> >>
> >> >> 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
> >> >> ---
> >> >> 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
> >>
> >> Per link in the beginning of this file it should be 82574l I guess?
> >>
> >> If yes, I'm using revision 3.4 and it's 13.3.27 is not about ICR.
> >>
> >> What it said are:
> >>
> >> "
> >> In MSI-X mode the bits in this register can be configured to
> >> auto-clear when the MSI-X interrupt message is sent, in order to
> >> minimize driver overhead, and when using MSI-X interrupt signaling. In
> >> systems that do not support MSI-X, reading the ICR register clears
> >> it's bits or writing 1b's clears the corresponding bits in this
> >> 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;
> >> >> +}
> >>
> >> Thanks
> >>
> >> >> +
> >> >> 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
> >> >>
> >>
>
>
[PATCH] e1000e: Added ICR clearing by corresponding IMS bit.
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
---
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
Re: [PATCH] e1000e: Added ICR clearing by corresponding IMS bit.
Patchew URL: https://patchew.org/QEMU/20200427152148.283771-1-and...@daynix.com/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash make docker-image-centos7 V=1 NETWORK=1 time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === TESTiotest-qcow2: 158 socket_accept failed: Resource temporarily unavailable ** ERROR:/tmp/qemu-test/src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0) /tmp/qemu-test/src/tests/qtest/libqtest.c:166: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0) ERROR - Bail out! ERROR:/tmp/qemu-test/src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0) make: *** [check-qtest-aarch64] Error 1 make: *** Waiting for unfinished jobs TESTiotest-qcow2: 159 Could not access KVM kernel module: No such file or directory --- raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=64e45f41b19b4eaebe20debcee6f7f36', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-q3q6urn6/src/docker-src.2020-04-27-13.56.36.8589:/var/tmp/qemu:z,ro', 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2. filter=--filter=label=com.qemu.instance.uuid=64e45f41b19b4eaebe20debcee6f7f36 make[1]: *** [docker-run] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-q3q6urn6/src' make: *** [docker-run-test-quick@centos7] Error 2 real12m46.958s user0m9.139s The full log is available at http://patchew.org/logs/20200427152148.283771-1-and...@daynix.com/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH] e1000e: Added ICR clearing by corresponding IMS bit.
Patchew URL: https://patchew.org/QEMU/20200427152148.283771-1-and...@daynix.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===
PASS 31 test-opts-visitor /visitor/opts/range/unvisited
PASS 32 test-opts-visitor /visitor/opts/range/beyond
PASS 33 test-opts-visitor /visitor/opts/dict/unvisited
==6243==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 4 fdc-test /x86_64/fdc/media_change
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
tests/test-coroutine -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl
--test-name="test-coroutine"
PASS 5 fdc-test /x86_64/fdc/sense_interrupt
---
PASS 8 fdc-test /x86_64/fdc/verify
PASS 9 fdc-test /x86_64/fdc/media_insert
PASS 10 fdc-test /x86_64/fdc/read_no_dma_1
==6253==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 1 test-coroutine /basic/no-dangling-access
PASS 2 test-coroutine /basic/lifecycle
==6253==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top:
0x7ffef1ae3000; bottom 0x7ff887c01000; size: 0x000669ee2000 (27547017216)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 3 test-coroutine /basic/yield
---
PASS 12 test-aio /aio/event/flush
PASS 13 test-aio /aio/event/wait/no-flush-cb
PASS 14 test-aio /aio/timer/schedule
==6269==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 11 fdc-test /x86_64/fdc/read_no_dma_18
PASS 15 test-aio /aio/coroutine/queue-chaining
PASS 16 test-aio /aio-gsource/flush
---
PASS 28 test-aio /aio-gsource/timer/schedule
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
tests/test-aio-multithread -m=quick -k --tap < /dev/null |
./scripts/tap-driver.pl --test-name="test-aio-multithread"
PASS 1 test-aio-multithread /aio/multi/lifecycle
==6274==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 2 test-aio-multithread /aio/multi/schedule
PASS 12 fdc-test /x86_64/fdc/read_no_dma_19
PASS 13 fdc-test /x86_64/fdc/fuzz-registers
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img
tests/qtest/ide-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl
--test-name="ide-test"
PASS 3 test-aio-multithread /aio/multi/mutex/contended
==6296==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 1 ide-test /x86_64/ide/identify
==6307==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 2 ide-test /x86_64/ide/flush
==6313==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 3 ide-test /x86_64/ide/bmdma/simple_rw
==6319==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 4 ide-test /x86_64/ide/bmdma/trim
==6325==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 4 test-aio-multithread /aio/multi/mutex/handoff
PASS 5 test-aio-multithread /aio/multi/mutex/mcs
PASS 6 test-aio-multithread /aio/multi/mutex/pthread
---
PASS 6 test-throttle /throttle/detach_attach
PASS 7 test-throttle /throttle/config_functions
PASS 8 test-throttle /throttle/accounting
==6342==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 9 test-throttle /throttle/groups
PASS 10 test-throttle /throttle/config/enabled
PASS 11 test-throttle /throttle/config/conflicting
---
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
tests/test-thread-pool -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl
--test-name="test-thread-pool"
PASS 1 test-thread-pool /thread-pool/submit
PASS 2 test-thread-pool /thread-pool/submit-aio
==6346==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 3 test-thread-pool /thread-pool/submit-co
PASS 4 test-thread-pool /thread-pool/submit-many
PASS 5 test-thread-pool /thread-pool/cancel
==6413==WARNING: ASan doesn't fully support makecontext/swapcontext functions
and may produce false positives in some cases!
PASS 6 test-thread-pool /thread-pool/cancel-async
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
tests/test-hbitmap -
[PATCH] e1000e: Added ICR clearing by corresponding IMS bit.
From: Andrew Melnychenko
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
---
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
