From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH] MSI / MSIX injection for Xen HVM Date: Thu, 01 Mar 2012 16:56:47 +0100 Message-ID: <4F4F9C3F.5020201@redhat.com> References: <1330536077.10387.57.camel@leeds.uk.xensource.com> <4F4E64B5.5080900@siemens.com> <1330597236.10387.70.camel@leeds.uk.xensource.com> <4F4F5BF5.6010206@siemens.com> <1330602678.10387.73.camel@leeds.uk.xensource.com> <4F4F71F0.4070109@redhat.com> <4F4F81AE.9080503@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Stefano Stabellini Cc: Jan Kiszka , xen-devel , "Wei Liu (Intern)" , QEMU-devel List-Id: xen-devel@lists.xenproject.org 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. 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. But you could take it further and create a separate subclass of apic-common that does absolutely nothing except register an MMIO memory region and use it to trap MSI writes. Basically an even more stripped down version than hw/kvm/apic.c, but using memory_region_init_io rather than memory_region_init_reservation. You would also get support for the monitor command inject-nmi (there is another hypercall for that in Xen IIRC). Paolo