çå: çå: çå: [PATCH] iommu/vt-d: Don't reject nvme host due to scope mismatch

[Jim,Yan]

Hi Baolu,

> -----éäåä-----
> åää: Lu Baolu [mailto:baolu.lu@xxxxxxxxxxxxxxx]
> åéæé: 2019å12æ24æ 14:27
> æää: Jim,Yan <jimyan@xxxxxxxxx>; Jerry Snitselaar <jsnitsel@xxxxxxxxxx>
> æé: iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> äé: Re: çå: çå: [PATCH] iommu/vt-d: Don't reject nvme host due to
> scope mismatch
> 
> Hi Jim,
> 
> On 2019/12/24 11:24, Jim,Yan wrote:
> >> -----éäåä-----
> >> åää: Lu Baolu [mailto:baolu.lu@xxxxxxxxxxxxxxx]
> >> åéæé: 2019å12æ23æ 21:05
> >> æää: Jim,Yan <jimyan@xxxxxxxxx>; Jerry Snitselaar
> >> <jsnitsel@xxxxxxxxxx>
> >> æé: iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> >> äé: Re: çå: [PATCH] iommu/vt-d: Don't reject nvme host due to scope
> >> mismatch
> >>
> >> Hi,
> >>
> >> On 2019/12/23 15:59, Jim,Yan wrote:
> >>>> -----éäåä-----
> >>>> åää: Jerry Snitselaar [mailto:jsnitsel@xxxxxxxxxx]
> >>>> åéæé: 2019å12æ20æ 17:23
> >>>> æää: Jim,Yan <jimyan@xxxxxxxxx>
> >>>> æé: joro@xxxxxxxxxx; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx;
> >>>> linux-kernel@xxxxxxxxxxxxxxx
> >>>> äé: Re: [PATCH] iommu/vt-d: Don't reject nvme host due to scope
> >>>> mismatch
> >>>>
> >>>> On Fri Dec 20 19, jimyan wrote:
> >>>>> On a system with an Intel PCIe port configured as a nvme host
> >>>>> device, iommu initialization fails with
> >>>>>
> >>>>>      DMAR: Device scope type does not match for 0000:80:00.0
> >>>>>
> >>>>> This is because the DMAR table reports this device as having scope
> >>>>> 2
> >>>>> (ACPI_DMAR_SCOPE_TYPE_BRIDGE):
> >>>>>
> >>>>
> >>>> Isn't that a problem to be fixed in the DMAR table then?
> >>>>
> >>>>> but the device has a type 0 PCI header:
> >>>>> 80:00.0 Class 0600: Device 8086:2020 (rev 06)
> >>>>> 00: 86 80 20 20 47 05 10 00 06 00 00 06 10 00 00 00
> >>>>> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>>>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 00 00
> >>>>> 30: 00 00 00 00 90 00 00 00 00 00 00 00 00 01 00 00
> >>>>>
> >>>>> VT-d works perfectly on this system, so there's no reason to bail
> >>>>> out on initialization due to this apparent scope mismatch. Add the
> >>>>> class
> >>>>> 0x600 ("PCI_CLASS_BRIDGE_HOST") as a heuristic for allowing DMAR
> >>>>> initialization for non-bridge PCI devices listed with scope bridge.
> >>>>>
> >>>>> Signed-off-by: jimyan <jimyan@xxxxxxxxx>
> >>>>> ---
> >>>>> drivers/iommu/dmar.c | 1 +
> >>>>> 1 file changed, 1 insertion(+)
> >>>>>
> >>>>> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index
> >>>>> eecd6a421667..9faf2f0e0237 100644
> >>>>> --- a/drivers/iommu/dmar.c
> >>>>> +++ b/drivers/iommu/dmar.c
> >>>>> @@ -244,6 +244,7 @@ int dmar_insert_dev_scope(struct
> >>>> dmar_pci_notify_info *info,
> >>>>> 		     info->dev->hdr_type != PCI_HEADER_TYPE_NORMAL) ||
> >>>>> 		    (scope->entry_type == ACPI_DMAR_SCOPE_TYPE_BRIDGE
> >> &&
> >>>>> 		     (info->dev->hdr_type == PCI_HEADER_TYPE_NORMAL &&
> >>>>> +			  info->dev->class >> 8 != PCI_CLASS_BRIDGE_HOST &&
> >>>>> 		      info->dev->class >> 8 != PCI_CLASS_BRIDGE_OTHER))) {
> >>>>> 			pr_warn("Device scope type does not match for %s\n",
> >>>>> 				pci_name(info->dev));
> >>>>> --
> >>>>> 2.11.0
> >>>>>
> >>>>> _______________________________________________
> >>>>> iommu mailing list
> >>>>> iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx
> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
> >>>>>
> >>> Actually this patch is similar to the commit:
> >>> ffb2d1eb88c3("iommu/vt-d: Don't
> >> reject NTB devices due to scope mismatch"). Besides, modifying DMAR
> >> table need OEM update BIOS. It is hard to implement.
> >>>
> >>
> >> For both cases, a quirk flag seems to be more reasonable, so that
> >> unrelated devices will not be impacted.
> >>
> >> Best regards,
> >> baolu
> >
> > Hi Baolu,
> > 	Thanks for your advice. And I modify the patch as follow.
> 
> I just posted a patch for both NTG and NVME cases. Can you please take a look?
> Does it work for you?
> 
> Best regards,
> baolu
> 
I have tested your patch. It does work for me. But I prefer my second version, it is more flexible, and may use for similar unknown devices.

> >
> >      On a system with an Intel PCIe port configured as a nvme host device,
> iommu
> >      initialization fails with
> >
> >          DMAR: Device scope type does not match for 0000:80:00.0
> >
> >      This is because the DMAR table reports this device as having scope 2
> >      (ACPI_DMAR_SCOPE_TYPE_BRIDGE):
> >
> >      but the device has a type 0 PCI header:
> >      80:00.0 Class 0600: Device 8086:2020 (rev 06)
> >      00: 86 80 20 20 47 05 10 00 06 00 00 06 10 00 00 00
> >      10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >      20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 00 00
> >      30: 00 00 00 00 90 00 00 00 00 00 00 00 00 01 00 00
> >
> >      VT-d works perfectly on this system, so there's no reason to bail out
> >      on initialization due to this apparent scope mismatch. Add the class
> >      0x06 ("PCI_BASE_CLASS_BRIDGE") as a heuristic for allowing DMAR
> >      initialization for non-bridge PCI devices listed with scope bridge.
> >
> >      Signed-off-by: jimyan <jimyan@xxxxxxxxx>
> >
> > diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index
> > eecd6a421667..50c92eb23ee4 100644
> > --- a/drivers/iommu/dmar.c
> > +++ b/drivers/iommu/dmar.c
> > @@ -244,7 +244,7 @@ int dmar_insert_dev_scope(struct
> dmar_pci_notify_info *info,
> >                       info->dev->hdr_type !=
> PCI_HEADER_TYPE_NORMAL) ||
> >                      (scope->entry_type ==
> ACPI_DMAR_SCOPE_TYPE_BRIDGE &&
> >                       (info->dev->hdr_type ==
> PCI_HEADER_TYPE_NORMAL &&
> > -                     info->dev->class >> 8 !=
> PCI_CLASS_BRIDGE_OTHER))) {
> > +                     info->dev->class >> 16 !=
> > + PCI_BASE_CLASS_BRIDGE))) {
> >                          pr_warn("Device scope type does not match
> for %s\n",
> >                                  pci_name(info->dev));
> >                          return -EINVAL;
> >
> >
> > Jim
> >