From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 4/4] KVM: x86: Enable MSI for assigned device Date: Wed, 8 Oct 2008 10:55:48 +0800 Message-ID: <200810081055.48842.sheng@linux.intel.com> References: <> <200810071359.58975.sheng@linux.intel.com> <48EB6751.9080901@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, "Han, Weidong" , "Kay, Allen M" To: Avi Kivity Return-path: Received: from mga09.intel.com ([134.134.136.24]:21480 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756220AbYJHC6S (ORCPT ); Tue, 7 Oct 2008 22:58:18 -0400 In-Reply-To: <48EB6751.9080901@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Tuesday 07 October 2008 21:42:41 Avi Kivity wrote: > Sheng Yang wrote: > > Seems we needn't tell userspace if MSI can be enabled. It's determined > > mostly by the device, and pci_enable_msi() checked that. > > > > So I think QEmu can expose MSI capability if the device got it. If it's > > fail to be enabled, just fall back to IRQ and return error to QEmu is > > enough, of course, QEmu should set MSI enable bit after kernel space > > done. > > Do we need to add the additional condition, "and if the host kernel > supports it"? Well, for VT-d, it's impossible because CONFIG_DMAR depends on CONFIG_PCI_MSI... And for non-VT-d(I don't know about PV or AMD IOMMU), from 2.6.18, MSI support have been added, before KVM merged. And we also got ifndef CONFIG_PCI_MSI, pci_enable_msi return -1. So we can still fall back to IRQ without error. How do you think? -- regards Yang, Sheng