linux-kernel - Re: [PATCH 4/5] PCI/IOV: simplify code by hotplug safe pci_get_domain_bus_and

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 21 Sep 2012 08:11:48 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Don Dutile <ddutile@...hat.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>, Jiang Liu <liuj97@...il.com>,
	Jiang Liu <jiang.liu@...wei.com>,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	Yijing Wang <wangyijing@...wei.com>,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH 4/5] PCI/IOV: simplify code by hotplug safe pci_get_domain_bus_and_slot()

On Fri, Sep 21, 2012 at 7:15 AM, Don Dutile <ddutile@...hat.com> wrote:
> On 09/21/2012 02:22 AM, Yinghai Lu wrote:
>>
>> On Thu, Sep 20, 2012 at 7:56 PM, Bjorn Helgaas<bhelgaas@...gle.com>
>> wrote:
>>>
>>> This is another thing I'm curious about.  How do you handle this
>>> situation today (before host bridge hot-add)?
>>>
>>> The DMAR I'm not so worried about because as far as I know, there's no
>>> such thing as a DMAR that's discovered by PCI enumeration.  We should
>>> discover it via ACPI, and that can happen before we enumerate anything
>>> behind a host bridge, so I don't really see any ordering problem
>>> between the DMAR and the PCI devices that would use it.
>>
>>
>> only need to have pci devices on that root bus scanned, and current intel
>> iommu
>> maintain one device scope to drhd with pointer to pci device... that
>> need to be fixed
>> too.
>>
> translation: you have an ACPI-DMAR setup bug?  a drhd can have multiple
> device
> scopes, one of which can be "all devices under bus X uses this IOMMU".
> If (dynamic) DMARs are scanned at root hot-plug time in ACPI hot-plug,
> the proper dmar-init should be completed before any PCI devs are scanned
> (and put into the proper iommu domain).

if you can check for-iommu branch,

http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=shortlog;h=refs/heads/for-iommu
current implementation:

after root bus plugged in,
drivers/acpi/pci_root_hp.c::handle_root_bridge_insert() ==>
acpi_bus_add ==> drivers/acpi/pci_root.c::acpi_pci_root_add ==>
arch/x86/pci/acpi.c::pci_acpi_scan_root
so all pci devices get scanned.

later
handl_root_bridge_insert ==>acpi_bus_add ==>
drivers/acpi/pci_root.c::acpi_pci_root_start==>
pcibios_reserouce_survey_bus/pci_assign_unassigned_bus_resource
and call iommu acpi_pci_driver .add aka
drivers/iommu/dmar.c::acpi_pci_iommu_add ==> register_iommu ==>
handle_iommu_add ==> dmar_parse_dev ==> dmar_parse_dev_scope ==>
dmar_parse_one_dev_scope

that dmar_parse_one_dev_scope will find pci device pointer and put it
back into dmaru device pointer array.

in the boot path, it the same, dev_scope is parsed later after pci
devices get scanned.

We really should remove that cache array for device pointer...

-Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/