qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cornelia Huck
Subject: Re: [Qemu-devel] [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386
Date: Mon, 23 Jul 2012 15:06:00 +0200

On Mon, 23 Jul 2012 15:18:49 +0300
Avi Kivity <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]