[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 11/11] pci: Convert msi_init() to Error and f
Re: [Qemu-devel] [PATCH v5 11/11] pci: Convert msi_init() to Error and fix callers to check it
Mon, 23 May 2016 20:51:36 +0800
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
On 05/23/2016 06:06 PM, Marcel Apfelbaum wrote:
On 05/17/2016 01:08 PM, Cao jin wrote:
On 05/15/2016 09:41 PM, Marcel Apfelbaum wrote:
That is why I am not quite sure about this device, msi has a relation
From its previous behaviour, it can be seen that it don`t treat 'on'
as 'auto'.(I am not sure why it is different with others)
Its previous behaviour treat msi_init`s failure as fatal, and lead to
device creation fail. According to Markus`s comments(if I understand
him right), this device has no non-msi variants.
Actually it has. The bridge needs msi for the SHPC controller, as you said.
If you look into shpc_interrupt_update function (hw/pci/shpc.c) you can
see it can fall
back to legacy interrupts.
The only complication here is that msi is needed only if shpc is present.
So maybe having msi=on/off/auto is OK.
msi=auto => if shpc not present or msi broken results in msi = off, else
msi = on
msi=on => fails if shpc present and msi broken
msi=off => use legacy interrupts if shpc is present
Basically the msi flag has no meaning if shpc not present.
Thanks for the hint, v6 is on the way:)
[Qemu-devel] [PATCH v5 03/11] megasas: Fix, Cao jin, 2016/05/06
[Qemu-devel] [PATCH v5 04/11] mptsas: change .realize function name, Cao jin, 2016/05/06
- Re: [Qemu-devel] [PATCH v5 01/11] fix some coding style problems, (continued)