On Thu, May 21, 2009 at 02:31:26PM +0100, Paul Brook wrote: > On Thursday 21 May 2009, Paul Brook wrote: > > > > MSI provides multiple edge triggered interrupts, whereas traditional > > > > mode provides a single level triggered interrupt. My guess is most > > > > devices will want to treat these differently anyway. > > > > > > So, is qemu_send_msi better than qemu_set_irq. > > > > Neither. pci_send_msi, which is a trivial wrapper around stl_phys. > > To clarify, you seem to be trying to fuse two largely separate features > together. > > MSI is a standard PCI device capability[1] that involves the device performing > a 32-bit memory write when something interesting occurs. These writes may or > may not be directed at a APIC. > > The x86 APIC has a memory mapped interface that allows generation of CPU > interrupts in response response to memory writes. These may or may not come > from an MSI capable PCI device. > > Paul > > [1] Note a *device* capability, not a bus capability. Paul, so I went over specs, and what you say about APIC here does not seem to be what Intel actually implemented. Specifically, Intel implemented *MSI support in APIC*. This lets PCI devices, but not the CPU, signal interrupts by memory writes. For example, after reset, when CPU writes to address 0xfee00000 this is an access to a reserved register in APIC, but when PCI device does write to 0xfee00000, this triggers an interrupt to destination 0. See section 9.12 in Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1 http://www.intel.com/Assets/PDF/manual/253668.pdf So it seems that what we need to do in pci is: if (!msi_ops || msi_ops->send_msi(address, data)) stl_phy(address, data); where send_msi is wired to apic_send_msi and where apic_send_msi returns an error for an address outside of the MSI range 0xfee00000 - 0xfeefffff Makes sense? -- MST -- 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