From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI? Date: Tue, 05 May 2009 15:08:40 +0300 Message-ID: <4A002C48.7000708@redhat.com> References: <20090505103028.GA15418@redhat.com> <20090505110415.GA4114@amt.cnet> <20090505110815.GC15418@redhat.com> <4A002996.6040803@redhat.com> <20090505120134.GE15418@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Sheng Yang , Matthew Wilcox , kvm@vger.kernel.org To: "Michael S. Tsirkin" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:55758 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751970AbZEEMIm (ORCPT ); Tue, 5 May 2009 08:08:42 -0400 In-Reply-To: <20090505120134.GE15418@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Michael S. Tsirkin wrote: > On Tue, May 05, 2009 at 02:57:10PM +0300, Avi Kivity wrote: > >> Michael S. Tsirkin wrote: >> >>> On Tue, May 05, 2009 at 08:04:15AM -0300, Marcelo Tosatti wrote: >>> >>> >>>> On Tue, May 05, 2009 at 01:30:28PM +0300, Michael S. Tsirkin wrote: >>>> >>>> >>>>> The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have >>>>> been merged for 2.6.30. However, I note that PCI spec allows devices to >>>>> support multiple vectors with MSI as well (support will be in linux >>>>> 2.6.30). >>>>> >>>>> Even though qemu for now only uses a single vector with MSI, it would >>>>> seem that it's better to make the kernel/user interface generic straight >>>>> away rather than add more ioctls later. What do you think? It might not >>>>> be too late to fix this for 2.6.30. >>>>> >>>>> >>>> Can't you use more than one KVM_ASSIGN_SET_MSIX_ENTRY call per assigned >>>> device? >>>> >>>> >>> Sure, but only one KVM_ASSIGN_SET_MSIX_NR. >>> >>> >>> >> MSIX_NR is the size of the table, while MSIX_ENTRY updates a single >> entry, if I read the code correctly. >> > > Right. So we'll need something like this for MSI as well. > Actually maybe MSIX_NR MSIX_ENTRY should be renamed to MSI_NR / MSI_ENTRY > and changed to do the right thing depending on the IRQ type? > Works for me. Sheng, is there a reason why it wasn't done like this? btw, it could be further simplified by using irqfd. Instead of the host device tying directly into kvm, it could just trigger an eventfd; and we could terminate the eventfd either in kvm (irqfd) or in qemu. -- error compiling committee.c: too many arguments to function