>> In particular, this requires interrupt handling to be done by the >guest -- >> The host shouldn't load the corresponding device driver or otherwise >access >> the device. Since the host kernel is not aware of the device semantics >it >> cannot acknowledge the interrupt at the device level. > >Tricky indeed. > >> As far as the host kernel is concerned the VM is a user level process. >We >> require the ability to forward interrupt handling to such entities. >The >> current kernel interrupt handling path doesn't allow deferring >interrupt >> handling _and_ acknowledgement. > >We don't support this model at all, and it doesn't appear to work >anyway. > >> 0. Adding an IRQ_DEFERRED mechanism to the interrupt handling path. >ISRs >> returning IRQ_DEFERRED will keep the interrupt masked until future >> acknowledge. > >Deadlock. If you get an IRQ for a guest and you block the IRQ until the >guest handles it you may (eg if the IRQ is shared) get priority >inversion >with another interrupt source on the same line the guest requires first >(eg disks and other I/O)
What if we will force the specific device to the end of the list. Once IRQ_NONE was returned by the other devices, we will mask the irq, forward the irq to the guest, issue a timer for 1msec. Motivation: 1msec is long enough for the guest to ack the irq + host unmask the irq + cancell the timer. (ping round-trip for a guest is about 100msec) If the timer poped, it will unmask irqs + run over the device list to check whether one of them has a pending irq. This will solve the deadlock possiblity in a small price of potential latency. ... >> Any ideas ? Thoughts ? > >Mask the interrupt in the main kernel, pass an event of some kind to the >guest. You can describe most devices from guest to kernel in a safe form >as > >device, bar, offset, register size, mask, bits to set, bits to clear > >(or bits to test when deciding if it is the irq source) > The problem is that each device has its own bits and it cannot be a general solution. Except that the device driver inside the guest should be changed because the host already disabled the irq/status for them. I know the above solution in not neat but we do want to contribute it. Any other ideas are welcome, 10x, Dor. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
