From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apBmt-00065k-C7 for qemu-devel@nongnu.org; Sun, 10 Apr 2016 05:36:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apBmp-0007it-VZ for qemu-devel@nongnu.org; Sun, 10 Apr 2016 05:36:11 -0400 Received: from [59.151.112.132] (port=17859 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apBmo-0007hQ-Mi for qemu-devel@nongnu.org; Sun, 10 Apr 2016 05:36:07 -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> From: Cao jin Message-ID: <570A1F1B.90502@cn.fujitsu.com> Date: Sun, 10 Apr 2016 17:38:35 +0800 MIME-Version: 1.0 In-Reply-To: <570A0CB7.1040509@redhat.com> Content-Type: text/plain; charset="windows-1252"; 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: Marcel Apfelbaum , Markus Armbruster Cc: qemu-devel@nongnu.org, mst@redhat.com, jasowang@redhat.com, alex.williamson@redhat.com, hare@suse.de, dmitry@daynix.com, pbonzini@redhat.com, jsnow@redhat.com, kraxel@redhat.com On 04/10/2016 04:20 PM, Marcel Apfelbaum wrote: > > Hi, > I'll let Markus to continue the review, it brings very valuable > information, > I will only try to answer the questions below. > >> Several questions on this topic: >> 1. How to confirm whether a device model has non-MSI variant? AFAICT, >> it is these who have msi property. >> > > MSI is required for PCI Express devices, optional for PCI devices. > Even if a PCI device supports MSI, it is strongly advised to support > legacy INTx for backward compatibility. > Bottom line, as far as I know, almost all PCI devices support legacy > interrupts. > (an exception is the ivshmem device that requires MSI) > >> 2. For those have non-MSI variant devices(have msi property), as I see >> in the code, they all have it on by default, So we won`t know it is >> user order, or user don`t set it at all. >> > > I didn't quite understand the sentence, but some devices have a > "use_msi" property that can be set by the user. If no such property exists, > we can assume the user "prefers" the msi version. > Hi, Sorry for my bad description. let me explain myself again. I think(guess), if a device model has msi property, it means this device model has non-msi variant. For those devices who has msi property, I see most of them will have it on by default. So when these devices initialize msi, qemu won`t know whether it is user order or not. If I understand Markus right: 1). If user orders msi on, when msi_init returns -ENOTSUP, It is error. Then I suggest to inform user "set msi=off and try again" 2). If user doesn`t order msi on(so device have msi on by default), when msi_init returns -ENOTSUP, I am ok with Markus`s suggestion: *caller should silently switch to the non-MSI variant* But now the condition is, qemu can`t distinguish whether user ordered msi or not, so for the condition 2) above, my suggestion is the same as 1) > >> If user don`t know msi and don`t set it on, I think it is acceptable >> to create the non-msi variant for user silently. But if it is user >> order, like you said, it is an error. >> > > I am not sure about this. At least a warning should be given IMHO. > >> So, how about: inform user to swich msi off and try again when >> encounter -ENOTSUP, no matter it is user order, or user doesn`t set it >> at all? >> > > Not all devices have an "msi" switch. If the board has msi broken and > the devices supports legacy interrupts, its OK to continue without MSI. > >> Actually in this v4, I do checked whether device has a msi property, >> like cover-letter said: >> >> 3. most devices have msi/msix(except vmxnet3 & pvscsi) property as >> a switch, if it has and is switched on, then msi_init() failure >> should results in return directly. So in this version, mptsas >> is updated >> > > I don't see a "msi" properties on PCIDevice class or VirtioPCIClass, are > you sure we have an msi switch for most of the PCI devices? > My bad, I didn`t limit the range. I mean the devices who will call msi_init, they mostly have msi(or msix, or both) property -- Yours Sincerely, Cao jin