Michael S. Tsirkin wrote: > It seems that if I just call apic_deliver_irq each time > I want to send MSI, things will work. > > However, large part of the msix code is managing IRQs versus kernel, > and I'm not sure it's a wise investment of effort to rip it all out. So > IMHO, what's missing is API that abstracts managing irq routes in kvm, > specifically abstract this stuff in some way: > kvm_get_irq_route_gsi > kvm_add_routing_entry > kvm_del_routing_entry > kvm_commit_irq_routes > All these are just games with qemu_irq objects. Should be a lot simpler in userspace. > kvm_set_irq > qemu_set_irq(). > How hard is that? > Should be pretty easy, once you get the hang of qemu_irq. > For now, this API could be a stub that just stores the routes somewhere, > and set_irq would call the local apic emulation, along the lines of: > > uint8_t dest = (addr_lo & MSI_ADDR_DEST_ID_MASK) > >> MSI_ADDR_DEST_ID_SHIFT; > uint8_t vector = (addr_hi & MSI_DATA_VECTOR_MASK) > >> MSI_DATA_VECTOR_SHIFT; > uint8_t dest_mode = (addr_lo >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1; > uint8_t trigger_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1; > uint8_t delivery_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & > 0x7; > apic_deliver_irq(dest, dest_mode, delivery_mode, vector, 0, > trigger_mode); > qemu_set_irq() eventually calls a callback that you specify; just set it do look up the entry and call apic_deliver_irq. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
