[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 1/3] x86/msi: harden stale pdev handling


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • Date: Thu, 17 Oct 2024 22:15:28 -0400
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jPZT5wcr0oCwNIfVfwipZlRogRfPVeQtTOls2m5X7HI=; b=RrD6aAqzDyqK0CN4nOLnF2BHdP4Wt3cpEDqlA6Kky3ZDldbcfSfAgqcwwJHyUj05iaZTKeF5XLsV4jk77PgK6W3Hc6lLWIYvvmxaoy2I269zt631tGy7AN1SYf2y98bnRwblYuyeqzpdPA+SN7ZgPCmzcpMJ1zGhOVMpNyR4y00bTA6UG4j1ftE0i9G2YTcDB+bgarpy86T2ueBkbtv+B5BJup8ObrIbGT6rishEmgm7EEcKH8Vuk4+JTga4JATuyodnlzDcwbDoaLrbMCTvzWUvhZ0e47wKqE22HMz2yHlMoFErlSz87yq69AwJiV432lIaSYAIqvBxIevRYyt0jQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TBeH5b8K0on5EiuDKME/YKoGUb0OONGXt9VQq/qqn65U9NEvcshkYfDGt2M01TGLYH8bTcx7F1EvEE4s9/4MoU5kgOZ8il3Sl0mKOfNyW2BcuZOyw5iE1Dpo+aDvAlgY9+3s7c3x2mmh1EuRWLLU6ndaGgUZ7aoWiEvPpgVz6Fm8j9TM0gmjnAlglgGPeEGXMX6hKz0vwNpRww2q2+nuWdpiR6LAVq8fE7FLOeGWkD1hgWyyJoYfUPfdhiyXwHJ6ZLmdbA8lY3b1Gku3+X7BZdcEYOCQQJq9l649drQSGWSulJhcTIZQpqzV5Z5X1Bx17/hhH+QmrxtOha6qwaREvA==
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 18 Oct 2024 02:15:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10/15/24 02:58, Jan Beulich wrote:
> On 11.10.2024 17:27, Stewart Hildebrand wrote:
>> --- a/xen/arch/x86/msi.c
>> +++ b/xen/arch/x86/msi.c
>> @@ -1243,7 +1243,12 @@ int pci_reset_msix_state(struct pci_dev *pdev)
>>  {
>>      unsigned int pos = pci_find_cap_offset(pdev->sbdf, PCI_CAP_ID_MSIX);
>>  
>> -    ASSERT(pos);
>> +    if ( !pos )
>> +    {
>> +        pdev->broken = true;
>> +        return -EFAULT;
>> +    }
>> +
>>      /*
>>       * Xen expects the device state to be the after reset one, and hence
>>       * host_maskall = guest_maskall = false and all entries should have the
>> @@ -1271,7 +1276,12 @@ int pci_msi_conf_write_intercept(struct pci_dev 
>> *pdev, unsigned int reg,
>>          entry = find_msi_entry(pdev, -1, PCI_CAP_ID_MSIX);
>>          pos = entry ? entry->msi_attrib.pos
>>                      : pci_find_cap_offset(pdev->sbdf, PCI_CAP_ID_MSIX);
>> -        ASSERT(pos);
>> +
>> +        if ( !pos )
>> +        {
>> +            pdev->broken = true;
>> +            return -EFAULT;
>> +        }
>>  
>>          if ( reg >= pos && reg < msix_pba_offset_reg(pos) + 4 )
>>          {
> 
> There are more instances of pci_find_cap_offset(..., PCI_CAP_ID_MSIX)
> which may want/need dealing with, even if there are no ASSERT()s there.

Yes, and some instances of pci_find_cap_offset(..., PCI_CAP_ID_MSI) too.

> Setting ->broken is of course a perhaps desirable (side) effect. Nevertheless
> I wonder whether latching the capability position once during device init
> wouldn't be an alternative (better?) approach.

I'll give this a try for the next rev.

> Finally I don't think -EFAULT is appropriate here. Imo it should be -ENODEV.

OK

> 
> Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.