On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
>
> On 06.03.2013, at 14:14, Gleb Natapov wrote:
>
> > On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
> >>> The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
> >>> KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
> >>
> >> Ah, I see. I don't see why it would. The fact that there is a "LAPIC"
> >> doesn't mean that the per-vcpu SET_INTERRUPT ioctl stops working. So if
> >> SET_IRQCHIP_TYPE(!none) breaks user-space interrupt controller emulation I
> >> would consider that a bug.
> >>
> > For x86 this is the case though. I do not see how it can't be. If
> > LAPIC is emulated in userspace SET_INTERRUPT is used to pass IRQ
> > vector that should be handled as a result of LAPIC emulation.
>
> So SET_INTERRUPT on a vcpu triggers a line on the LAPIC emulation in that
> vcpu? For us it directly controls the CPU interrupt pin.
>
No SET_INTERRUPT on a vcpu tells vcpu to which vector in IDT it needs to
jump immediately. LAPIC is really part of a cpu and we cut it and put into
userspace, so interface between userspace LAPIC emulation is really low
level and has to be synchronous. X86 has two interrupt lines NMI and INTR
and we do not have interface to trigger the later. KVM_IRQ_LINE works on
GSI lines which do not go into CPU directly. They go either via PIC (which
triggers INTR or APIC LINT0) or via IOAPIC which on real HW communicates
with APICs via bus, but in our emulation just calls APICs directly.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
