From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aw6C0-00089X-9L for qemu-devel@nongnu.org; Fri, 29 Apr 2016 07:02:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aw6Bo-0003Fr-I5 for qemu-devel@nongnu.org; Fri, 29 Apr 2016 07:02:34 -0400 Received: from [59.151.112.132] (port=16499 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aw6Bn-0003BS-Vs for qemu-devel@nongnu.org; Fri, 29 Apr 2016 07:02:28 -0400 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> From: Cao jin Message-ID: <5723294F.2000501@cn.fujitsu.com> Date: Fri, 29 Apr 2016 17:28:47 +0800 MIME-Version: 1.0 In-Reply-To: <87wpo3gi60.fsf@dusky.pond.sub.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit 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: Markus Armbruster , Marcel Apfelbaum Cc: 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 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. 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? -- Yours Sincerely, Cao jin