From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v2 0/9] qemu-kvm: Clean up and enhance MSI irqchip support Date: Wed, 27 Apr 2011 16:39:27 +0300 Message-ID: <4DB81C8F.1070205@redhat.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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm@vger.kernel.org" , "Michael S. Tsirkin" To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:17911 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756216Ab1D0Nje (ORCPT ); Wed, 27 Apr 2011 09:39:34 -0400 In-Reply-To: <4DB81AA4.9060904@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. > > 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? Maybe an intermediate solution is to move kvm_hpet_msi_update() (with a neutral name) into msi.c and have hpet call it whenever things change. So hpet.c isn't aware of kvm directly. -- error compiling committee.c: too many arguments to function