From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apYeA-0002P6-P7 for qemu-devel@nongnu.org; Mon, 11 Apr 2016 06:00:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apYe6-0007v6-Nu for qemu-devel@nongnu.org; Mon, 11 Apr 2016 06:00:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apYe6-0007us-GO for qemu-devel@nongnu.org; Mon, 11 Apr 2016 06:00:38 -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> From: Marcel Apfelbaum Message-ID: <570B75BA.3050800@redhat.com> Date: Mon, 11 Apr 2016 13:00:26 +0300 MIME-Version: 1.0 In-Reply-To: <570A1F1B.90502@cn.fujitsu.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: Cao jin , 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 12:38 PM, Cao jin wrote: > > > 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" If the user *specifically* asked for msi=on (setting a property) is OK to fail the device init process. > 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 we can't distinguish between the cases, 2 would not be user-friendly. Once it would be possible to differentiate we could go for 2. Thanks, Marcel >> >>> 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 > > >