Paul Brook wrote:
Instead of writing directly, let's abstract it behind a qemu_set_irq().
This is easier for device authors. The default implementation of the
irq callback could write to apic memory, while for kvm we can directly
trigger the interrupt via the kvm APIs.
I'm still not convinced.
A tight coupling between PCI devices and the APIC is just going to cause us
problems later one. I'm going to come back to the fact that these are memory
writes so once we get IOMMU support they will presumably be subject to
remapping by that, just like any other memory access.
I'm not suggesting the qemu_irq will extend all the way to the apic.
Think of it as connecting the device core with its interrupt unit.
Even ignoring that, qemu_irq isn't really the right interface. A MSI is a one-
off event, not a level state. OTOH stl_phys is exactly the right interface.
The qemu_irq callback should do an stl_phys(). The device is happy
since it's using the same API it uses for non-MSI. The APIC is happy
since it isn't connected directly to the device. stl_phys() is happy
since it sees more traffic and can serve more ads. kvm is happy since
it can hijack the callback to throw the interrupt directly into the kernel.
The KVM interface should be contained within the APIC implementation.
Tricky, but doable.
--
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
