From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v2 0/9] qemu-kvm: Clean up and enhance MSI irqchip support Date: Wed, 27 Apr 2011 16:10:04 +0200 Message-ID: <4DB823BC.7050604@siemens.com> References: <4DB7C56D.8040503@redhat.com> <4DB7DB24.8060403@siemens.com> <4DB7DC11.1010308@redhat.com> <4DB7DC8B.1030402@siemens.com> <4DB7DE7A.4000608@redhat.com> <4DB7FC21.8000203@siemens.com> <4DB80826.5010706@redhat.com> <4DB81AA4.9060904@siemens.com> <4DB81C8F.1070205@redhat.com> <4DB8201C.1000607@siemens.com> <20110427140230.GL15788@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Marcelo Tosatti , "kvm@vger.kernel.org" To: "Michael S. Tsirkin" Return-path: Received: from david.siemens.de ([192.35.17.14]:23605 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932815Ab1D0OKJ (ORCPT ); Wed, 27 Apr 2011 10:10:09 -0400 In-Reply-To: <20110427140230.GL15788@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-04-27 16:02, Michael S. Tsirkin wrote: > On Wed, Apr 27, 2011 at 03:54:36PM +0200, Jan Kiszka wrote: >> On 2011-04-27 15:39, Avi Kivity wrote: >>> On 04/27/2011 04:31 PM, Jan Kiszka wrote: >>>>> A hash table is indeed overcomplicated for this. >>>>> >>>>> How about a replacement for stl_phys() for the MSI case: >>>>> >>>>> - stl_phys(timer->fsb>> 32, timer->fsb& 0xffffffff); >>>>> + msi_stl_phys(timer->fsb>> 32, timer->fsb& 0xffffffff, >>>>> &timer->msi_cache); >>>>> >>>>> msi_stl_phys(target_phys_addr_t addr, uint32_t data, MSICache *cache) >>>>> { >>>>> if (kvm_msi_enabled()&& addr& MSI_ADDR_MASK == msi_base_addr) { >>>>> if (cache->addr != addr || cache->data != data) { >>>>> kvm_update_msi_cache(cache, addr, data); >>>>> } >>>>> kvm_irq_line(cache->gsi, 1); >>>>> kvm_irq_line(cache->gsi, 0); >>>>> return; >>>>> } >>>>> stl_phys(addr, data); >>>>> } >>>> >>>> I was planning for a MSI short-path anyway. Also for TCG, it's pointless >>>> to go through lengthy stl_phys if we know it's supposed to be an MSI >>>> message. >>> >>> I don't think tcg will see much benefit; the decoding path through >>> hw/apic.c isn't complicated. >> >> stl_phys itself is non-trivial, e.g. due to phys_page_find. >> >>> >>>>> but at least it means that devices don't need significant >>>>> change for kvm support. We could also allocate a single gsi for use in >>>>> hw/apic.c so hacks like using DMA to generate an MSI will work (will be >>>>> slow, though). >>>> >>>> Needs some thoughts, maybe it will work. Though, it's not yet clear to >>>> me if we can drop the kvm hooks from msi/msix.c and still support >>>> vhost/dev-assignment this way. Just to keep hpet.c cleaner, I don't >>>> think it's worth the effort. >>> >>> Right. Do we have other users of MSI besides PCI? >> >> And HPET? Not yet. IOMMU will become another user. Maybe future chipsets >> will include more non-PCI devices that issue MSIs. > > In theory any device can issue writes into the memory range that > apic maps to MSI and I don't think apic can tell what caused this. Not the APIC, but the PCI bridge and specifically the IOMMU can and do. But that does not help us here. > > Another issue is the reverse: regular memory address can be put > in the MSIX/MSI field and the result should be a regular memory > write. Yes, that's a separate issue: Requests issued by the CPUs have to be told apart from those issued by devices. I'm trying to address this for a while (to clean up the APIC page mappings), but it's hairy and incomplete yet. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux