[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] MSI / MSIX injection for Xen HVM
On Tue, 3 Apr 2012, Wei Liu (Intern) wrote: > On Thu, 2012-03-01 at 15:56 +0000, Paolo Bonzini wrote: > > Il 01/03/2012 15:50, Stefano Stabellini ha scritto: > > >>> > > That is a good point actually: we already have lapic emulation in > > >>> > > Xen, > > >>> > > it makes sense to have apic-msi in Xen too. > > >>> > > We would still need the changes to msi_notify and msix_notify > > >>> > > though. > > >> > > > >> > Why? The stores would just go to the Xen interrupt controller MMIO > > >> > area > > >> > which then does the xc_hvm_inject_msi. > > > > > > Because msi(x)_notify is called by QEMU's emulated devices: it is not > > > possible from QEMU to cause an emulation trap in Xen on behalf of the > > > guest. > > > > I'm not a QEMU expert, so following question may be dumb. However I do > care about a cleaner implementation. So please be patient with me. :-) > > > msi{x,}_notify doesn't have to go to Xen MMIO emulation, so in Wei's > > patch you don't need anymore the msi{,x}_notify parts, only apic_send_msi. > > > > I don't quite understand "you don't need anymore the msi{,x}_notify > parts". Virtio PCI invokes msi_notify directly. If I don't hook up > msi{,x}_notify, how can I deal with devices like Virtio PCI? msi_notify calls stl_le_phys that is internal to QEMU and goes to the emulated local apic in QEMU. So you can just hook into the emulated local apic like KVM, rather than adding a new hook in msi{,x}_notify. The fact that the real emulated local apic is in Xen is very confusing for the sake of this discussion. The emulated local apic in Xen is not involved in Paolo's suggestion. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |