> > ok, I'm missing something here. (and trying to catch up via Vol 3A > > is taking too long). > > I thought the order is: > > (1) qemu raises interrupt > > (2) qemu calls kvm ioctl > > (3) guest interrupt handler > > (4) guest clears interrupt by writing ~0 to qxl > > ram_header->int_mask. > > (5) qemu detects this next time it raises interrupt. > > > so where does qemu/hw/qxl.c get a chance to see this masking > > *immediately* after it raises the interrupt, i.e. before (2) above, > > since otherwise there is a timeout here, you need to add a > > callback, > > it gets complicated, and then the unconditional two way sending > > looks > > much better. (I'm already on the same page with you on not needing > > guest capabilities at this point, even though for the future it did > > look like a good thing to have). > > There are two registers: > > (1) the interrupt enable register (aka ram->int_mask) > (2) the interrupt status register (aka ram->int_pending) > > qemu sets the irq bit in the status register each time the irq > condition > is meet. qemu actually raises an irq in case the guest has the irq > bit > set in the enable register. guest acks the irq by clearing the irq > bit > in the status register (then issue QXL_IO_UPDATE_IRQ to notify qemu > that > it touched interrupt registers, which we need because our registers > in > memory not mmio space). > > So qxl can simply look at the enable register bit to figure whenever > the > guest is interested in specific interrupts or not.
Hans and myself discussed offline the current windows driver implementation. In short, it sets ram->int_mask to ~0, thereby claiming to support all 32 interrupts (including those we haven't thought of yet..). > > cheers, > Gerd > >
