aboutsummaryrefslogtreecommitdiff
path: root/hw/ipmi
diff options
context:
space:
mode:
authorAkihiko Odaki <akihiko.odaki@daynix.com>2023-06-02 16:25:16 +0900
committerJason Wang <jasowang@redhat.com>2023-07-07 16:35:12 +0800
commite414270000e9f7fe2a56d314ab85259aeaf1bd91 (patch)
tree28e8ad362081c7787f081c46184bed46111c94bc /hw/ipmi
parentb6aeee02980e193f744f74c48fd900940feb2799 (diff)
downloadqemu-e414270000e9f7fe2a56d314ab85259aeaf1bd91.zip
qemu-e414270000e9f7fe2a56d314ab85259aeaf1bd91.tar.gz
qemu-e414270000e9f7fe2a56d314ab85259aeaf1bd91.tar.bz2
e1000e: Add ICR clearing by corresponding IMS bit
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>
Diffstat (limited to 'hw/ipmi')
0 files changed, 0 insertions, 0 deletions