Re: [Qemu-devel] [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386

[Avi Kivity]

On 07/23/2012 03:04 PM, Cornelia Huck wrote:
> 
> OK, so I was reading through this thread since I want to add irqfd
> support for s390, but we don't have any kind of "irqchip".
> 
> The understanding I got so far is that !s390 architectures have some
> kind of mechanism that allows them to "route" an interrupt between a
> device and a cpu, meaning that there's a fixed tie-in between a device
> and a cpu. 

It's not fixed, but it changes rarely.  Various interrupt routers can be
programmed to change the route, but guests do so only rarely.

> If that's correct, I don't see how to model irqfds via
> this irqchip infrastructure for s390.
> 
> Here's in a nutshell how (external and I/O) interrupts work on s390:
> 
> - Interrupts have an internal prioritation, that means different types
> of interrupts (external, I/O, machine check, ...) take precedent over
> other types
> 
> - External and I/O interrupts are "floating", i. e. they are not tied
> to a specific cpu, but can be delivered to any cpu that has external
> resp. I/O interrupts enabled
> 
> - Interrupts take payload with them that defines which device they are
> for
> 
> 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.

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.
 While you don't have an irqchip, you do have asynchronous interrupt
injection, yes?  That's what irqchip really is all about.

-- 
error compiling committee.c: too many arguments to function