Hi, I am learning the relevant code of kvm interrupt simulation, I found that when pic_get_irq returns -1, pic_poll_read returns 0x07; when the return value of pic_get_irq is not -1, pic_poll_read directly returns the corresponding irq number without set the Bit 7. But according to the relevant description of the Poll Command section in "8259A PROGRAMMABLE INTERRUPT CONTROLLER", the correct hardware behavior should be The byte returned during the I/O read contains a 1 in Bit 7 if there is an interrupt, and the binary code of the highest priority level in Bits 2:0. The corresponding code is as follows: static u32 pic_poll_read(struct kvm_kpic_state *s, u32 addr1) { int ret; ret = pic_get_irq(s); if (ret >= 0) { if (addr1 >> 7) { s->pics_state->pics[0].isr &= ~(1 << 2); s->pics_state->pics[0].irr &= ~(1 << 2); } s->irr &= ~(1 << ret); pic_clear_isr(s, ret); if (addr1 >> 7 || ret != 2) pic_update_irq(s->pics_state); } else { ret = 0x07; pic_update_irq(s->pics_state); } return ret; } In Qemu, I found the emulation code according to the hardware manual as follows: static uint64_t pic_ioport_read(void *opaque, hwaddr addr, unsigned size) { PICCommonState *s = opaque; int ret; if (s->poll) { ret = pic_get_irq(s); if (ret >= 0) { pic_intack(s, ret); ret |= 0x80; // set the Bit 7 } else { ret = 0; } s->poll = 0; } else { if (addr == 0) { if (s->read_reg_select) { ret = s->isr; } else { ret = s->irr; } } else { ret = s->imr; } } trace_pic_ioport_read(s->master, addr, ret); return ret; } I would like to ask, why is the simulation of pic_poll_read in kvm inconsistent with the hardware manual? Is this correct? What is the meaning of 0x07 returned by pic_poll_read when pic_get_irq returns -1? Indicates a spurious interrupt? When the return value of pic_get_irq is not -1, why is Bit 7 of the return value of pic_poll_read not set? Thanks. :-) Jinliang Zheng