From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI? Date: Tue, 5 May 2009 15:39:49 +0300 Message-ID: <20090505123949.GF15418@redhat.com> References: <20090505103028.GA15418@redhat.com> <20090505110415.GA4114@amt.cnet> <20090505110815.GC15418@redhat.com> <4A002996.6040803@redhat.com> <20090505120134.GE15418@redhat.com> <4A002C48.7000708@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Marcelo Tosatti , Sheng Yang , Matthew Wilcox , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:33782 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751970AbZEEMkv (ORCPT ); Tue, 5 May 2009 08:40:51 -0400 Content-Disposition: inline In-Reply-To: <4A002C48.7000708@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, May 05, 2009 at 03:08:40PM +0300, Avi Kivity wrote: > 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. This probably is outside the scope for 2.6.30 :) -- MST