From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aw7pN-000869-4O for qemu-devel@nongnu.org; Fri, 29 Apr 2016 08:47:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aw7pB-0005MY-9H for qemu-devel@nongnu.org; Fri, 29 Apr 2016 08:47:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aw7pB-0005J2-4N for qemu-devel@nongnu.org; Fri, 29 Apr 2016 08:47:13 -0400 From: Markus Armbruster References: <1459855602-16727-1-git-send-email-caoj.fnst@cn.fujitsu.com> <1459855602-16727-6-git-send-email-caoj.fnst@cn.fujitsu.com> <87pou0sd4u.fsf@dusky.pond.sub.org> <5708F33B.2040000@cn.fujitsu.com> <570A0CB7.1040509@redhat.com> <570A1F1B.90502@cn.fujitsu.com> <570B75BA.3050800@redhat.com> <87wpo3gi60.fsf@dusky.pond.sub.org> <5723294F.2000501@cn.fujitsu.com> Date: Fri, 29 Apr 2016 14:46:59 +0200 In-Reply-To: <5723294F.2000501@cn.fujitsu.com> (Cao jin's message of "Fri, 29 Apr 2016 17:28:47 +0800") Message-ID: <8737q41t18.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v4 5/5] Add param Error ** for msi_init() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cao jin Cc: Marcel Apfelbaum , mst@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org, alex.williamson@redhat.com, hare@suse.de, dmitry@daynix.com, pbonzini@redhat.com, jsnow@redhat.com, kraxel@redhat.com Cao jin writes: > Hi Markus, > sorry for replying so late, I am stucked by other tasks for a while. > > On 04/12/2016 07:50 PM, Markus Armbruster wrote: >> >> Examine how it uses msi_init(). That's how we give a PCI device >> capability MSI. If the device model treats msi_init() failure as fatal, >> it doesn't have a non-MSI variant. >> >> Some device models let the user ask for MSI with a property, and make >> the msi_init() call depend on the property. The property is commonly >> called "msi" or "use_msi", with values "on" and "off". >> >> msi=off then works as expected: you get the variant without MSI. >> >> The meaning of msi=on depends on how msi_init() failure is handled. If >> it's fatal, then msi=on works as expected: you get the variant with MSI. >> But if it's not fatal, then you may or may not get it, which I consider >> a grossly misleading user interface. >> >> To clean this up, we could add msi=auto, and move the non-fatal behavior >> from msi=on to msi=auto. >> >> Same for MSI-X with msix_init() and property "msix". >> > Let me try to understand your meaning, correct me pls if I am wrong: > > replace the msi property type from bit/int to enum OnOffAuto(it seems > need a tiny surgery for device structure), and default to auto. Then > process going to look like this: > > (msi property = auto) means enable msi by default. If msi_init fail, > we switch to the non-MSI variant; If msi_init success, we got msi > variant. You got it. > Another condition I want to mention, ahci, pvscsi & vmxnet3 don`t have > msi property, and when msi_init fail, they all will use intx. One > thing need to be confirmed: whether they need a msi property or not? While I don't particularly like additional configuration knobs, I like the "try to use MSI, fall back to INTx silently" behavior even less. I'd welcome such a property. Can guarantee the respective maintainers will agree with me, of course.