On Tue, Jan 15, 2013 at 05:25:13PM +0100, Alexander Graf wrote:

On 01/15/2013 04:17 PM, Gleb Natapov wrote:

quoted

On Tue, Jan 15, 2013 at 02:04:47PM +0000, Peter Maydell wrote:

quoted

On 15 January 2013 12:52, Gleb Natapov[off-list ref]  wrote:

quoted

On Tue, Jan 15, 2013 at 12:15:01PM +0000, Peter Maydell wrote:

quoted

On 15 January 2013 09:56, Gleb Natapov[off-list ref]  wrote:

quoted

quoted

ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip

CPU level interrupt should use KVM_INTERRUPT instead.

No, that would be wrong. KVM_INTERRUPT is for interrupts which must be
delivered synchronously to the CPU. KVM_IRQ_LINE is for interrupts which
can be fed to the kernel asynchronously. It happens that on x86 "must be
delivered synchronously" and "not going to in kernel irqchip" are the same, but
this isn't true for other archs. For ARM all our interrupts can be fed
to the kernel asynchronously, and so we use KVM_IRQ_LINE in all
cases.

I do no quite understand what you mean by synchronously and
asynchronously.

Synchronously: the vcpu has to be stopped and userspace then
feeds in the interrupt to be taken when the guest is resumed.
Asynchronously: any old thread can tell the kernel there's an
interrupt, and the guest vcpu then deals with it when needed
(the vcpu thread may leave the guest but doesn't come out of
the host kernel to qemu).

quoted

The difference between KVM_INTERRUPT and KVM_IRQ_LINE line
is that former is used when destination cpu is known to userspace later
is used when kernel code is involved in figuring out the destination.

This doesn't match up with Avi's explanation at all.

quoted

The
injections themselves are currently synchronous for both of them on x86
and ARM. i.e vcpu is kicked out from guest mode when interrupt need to
be injected into a guest and vcpu state is changed to inject interrupt
during next guest entry. In the near feature x86 will be able to inject
interrupt without kicking vcpu out from the guest mode does ARM plan to
do the same? For GIC interrupts or for IRQ/FIQ or for both?

quoted

There was a big discussion thread about this on kvm and qemu-devel last
July (and we cleaned up some of the QEMU code to not smoosh together
all these different concepts under "do I have an irqchip or not?").

Do you have a pointer?

  http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02460.html
and there was a later longer (but less clear) thread which included
this mail from Avi:
  http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02872.html
basically explaining that the reason for the weird synchronous
KVM_INTERRUPT API is that it's emulating a weird synchronous
hardware interface which is specific to x86. ARM doesn't have
a synchronous interface in the same way, so it's much more
straightforward to use KVM_IRQ_LINE.

OK. I see. So basically Avi saw KVM_INTERRUPT as an oddball interface
required only for APIC emulation in userspace. It is used for PIC also,
where this is not strictly needed, but this is for historical reasons
(KVM_IRQ_LINE was introduces late and it is GSI centric on x86).

Thank you for the pointer.

Yeah, please keep in mind that KVM_INTERRUPT is not a unified
interface either. In fact, it is asynchronous on PPC :). And it's
called KVM_S390_INTERRUPT on s390 and also asynchronous. X86 is the
oddball here.

KVM_INTERRUPT needs vcpu fd to be issues. Usually such ioctls are
issued only by vcpu thread which makes them synchronous and vcpu_load()
synchronise them anyway if the rule is not met. And sure enough those
KVM_S390_INTERRUPT/KVM_INTERRUPT are special cased in kvm_vcpu_ioctl()
to not call vcpu_load(), sigh :(

There was an idea to change vcpu ioctls to kvm syscall which would have
made it impossible to use KVM_INTERRUPT asynchronously.

But I don't care whether we call the ioctl to steer CPU interrupt
pins KVM_INTERRUPT, KVM_S390_INTERRUPT or KVM_IRQ_LINE, as long as
the code makes it obvious what is happening.

Some consistency would be nice though. You do not always look at the
kernel code when you read userspace code and iothread calling KVM_INTERRUPT
would have made me suspicious.

--
			Gleb.