On 07/23/2012 04:06 PM, Cornelia Huck wrote: > 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. Can you write them from a different cpu and expect them to take effect? How do you emulate an interrupt with a large guest? You have to update the flags in the control blocks for all vcpus; then restore them when the interrupt is delivered? >> 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. Sure. >> 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. Ok. The difference between irqfd and the ioctl is that with irqfd everything (the payload in your case, the interrupt number for others) is prepared beforehand, while with the ioctl the extra information is delivered with the ioctl. -- error compiling committee.c: too many arguments to function -- 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
