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 17:01:09 +0300 Message-ID: <4DB821A5.70306@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> <4DB81C8F.1070205@redhat.com> <4DB8201C.1000607@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]:38012 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756212Ab1D0OBO (ORCPT ); Wed, 27 Apr 2011 10:01:14 -0400 In-Reply-To: <4DB8201C.1000607@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 04/27/2011 04:54 PM, Jan Kiszka wrote: > >> > >> 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. That is true. But consider that MSI delivery has to emulate interrupt injection through the IDT... > > > > 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. > > Without caching, you need per-vector tracking to refresh or drop routes. > That's what the hooks are about. Right, my proposal doesn't really change your code, it simply moves the kvm specific parts away from hpet.c. Instead of a general cache, the caller is supposed to provide a unique KVMMsiMessage per msi vector, so there is no cache management. > Intermediate solutions (like hacking msi.c now) are one thing. We also > have to know where we can go to long-term. The really general case (allow generating an MSI via DMA, or allow the device to write to non-MSI addresses via MSI generation) needs the full blown cache. But while I've seen these techniques actually used, I hope they're rare. -- error compiling committee.c: too many arguments to function