On Tue, Jul 14, 2015 at 05:15:11PM -0500, Bjorn Helgaas wrote:
>On Tue, Jun 30, 2015 at 03:37:14PM +0800, Wei Yang wrote:
>> VF BARs are RO zero, so updating VF BARs will not take any effect.
>> See the SR-IOV spec r1.1, sec 3.4.1.11.
>>
>> Signed-off-by: Wei Yang <weiyang@xxxxxxxxxxxxxxxxxx>
>> ---
>> drivers/pci/setup-res.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
>> index 232f925..334b394 100644
>> --- a/drivers/pci/setup-res.c
>> +++ b/drivers/pci/setup-res.c
>> @@ -37,6 +37,13 @@ void pci_update_resource(struct pci_dev *dev, int resno)
>> struct resource *res = dev->resource + resno;
>>
>> /*
>> + * Per SRIOV SPEC 3.4.1.11, VF BARs are RO zero.
>> + * If this is a VF, just return.
>> + */
>> + if (dev->is_virtfn)
>> + return;
>
>Does this fix a problem? Are you seeing the "BAR %d: error updating"
>message?
>
Yes, I see the "error updating" message when doing vfio pass through.
>I wouldn't think we would even call pci_update_resource() for VFs, except
>for pci_restore_bars(). Maybe we should check there?
>
This happens after commit <6eb7018705de> ("vfio-pci: Move idle devices to
D3hot power state"). When do vfio, it will set the power state, and which in
turn update the BAR.
Hmm... yes, maybe the pci_restore_bars() is a good place to check.
>If the PCI core is assigning space directly to VF BARs and trying to update
>them, I'd like to know about that rather than silently ignoring it.
>
Ok, so I would add a warning at this place.
>> +
>> + /*
>> * Ignore resources for unimplemented BARs and unused resource slots
>> * for 64 bit BARs.
>> */
>> --
>> 1.7.9.5
>>
--
Richard Yang
Help you, Help me
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
