On Mon, 23 Jul 2012 15:18:49 +0300 Avi Kivity <avi@xxxxxxxxxx> wrote: > > So, for example, if a specific subchannel (=device) has pending status > > and an I/O interrupt is to be generated, this interrupt remains pending > > until an arbitrary cpu is enabled for I/O interrupts. If several cpus > > are enabled for I/O interrupts, any of them may be interrupted. > > This may be costly to emulate. On x86 we do not have access to a > guest's interrupt status while it is running. Is this not the case for > s390? > > Oh, let me guess. You write some interrupt descriptor in memory > somewhere, issue one of your famous instructions, and the hardware finds > a guest vcpu and injects the interrupt. Basically, we have some flags in our control block we can set so that the cpu drops out of SIE whenever external/I/O/... interrupts are enabled and then have the host do the lowcore updates, psw swaps, etc. > > x86 has a "least priority" mode which is similar to what you're > describing, but I don't think we emulate it correctly. > > > When an > > I/O interrupt is delivered on a cpu, the cpu's lowcore contains the > > interrupt payload which defines the subchannel (=device) the interrupt > > is for. > > > > Any idea on how this architecture can be married with the irqchip > > concept is welcome. If all else fails, would a special irqfd concept > > for !irqchip be acceptable? > > I don't see an issue. You need an arch-specific irqfd configuration > ioctl (or your own data field in the existing ioctl) that defines the > payload. Then the kernel installs a poll function on that eventfd that, > when called, does the magic sequence needed to get the interrupt there. If extending the existing ioctl is acceptable, I think we will go that route. > While you don't have an irqchip, you do have asynchronous interrupt > injection, yes? That's what irqchip really is all about. You mean injection via ioctl() that is asynchronous to vcpu execution? Yes, although we use a different ioctl than the others. Cornelia -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
