linux-kernel - Re: [PATCH 0/2] Introduce PCI_FIXUP

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <5FD9EE6E.1040505@hisilicon.com>
Date:   Wed, 16 Dec 2020 19:24:30 +0800
From:   Zhou Wang <wangzhou1@...ilicon.com>
To:     Bjorn Helgaas <helgaas@...nel.org>,
        Zhangfei Gao <zhangfei.gao@...aro.org>
CC:     Arnd Bergmann <arnd@...db.de>, Joerg Roedel <joro@...tes.org>,
        "Bjorn Helgaas" <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Hanjun Guo <guohanjun@...wei.com>,
        Sudeep Holla <sudeep.holla@....com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        jean-philippe <jean-philippe@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        <kenneth-lee-2012@...mail.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@...r.kernel.org>,
        "open list:IOMMU DRIVERS" <iommu@...ts.linux-foundation.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        Thanu Rangarajan <Thanu.Rangarajan@....com>,
        Souvik Chakravarty <Souvik.Chakravarty@....com>,
        wanghuiqiang <wanghuiqiang@...wei.com>
Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

On 2020/6/23 23:04, Bjorn Helgaas wrote:
> On Fri, Jun 19, 2020 at 10:26:54AM +0800, Zhangfei Gao wrote:
>> Have studied _DSM method, two issues we met comparing using quirk.
>>
>> 1. Need change definition of either pci_host_bridge or pci_dev, like adding
>> member can_stall,
>> while pci system does not know stall now.
>>
>> a, pci devices do not have uuid: uuid need be described in dsdt, while pci
>> devices are not defined in dsdt.
>>     so we have to use host bridge.
> 
> PCI devices *can* be described in the DSDT.  IIUC these particular
> devices are hardwired (not plug-in cards), so platform firmware can
> know about them and could describe them in the DSDT.
> 
>> b,  Parsing dsdt is in in pci subsystem.
>> Like drivers/acpi/pci_root.c:
>>        obj = acpi_evaluate_dsm(ACPI_HANDLE(bus->bridge), &pci_acpi_dsm_guid,
>> 1,
>>                                 IGNORE_PCI_BOOT_CONFIG_DSM, NULL);
>>
>> After parsing DSM in pci, we need record this info.
>> Currently, can_stall info is recorded in iommu_fwspec,
>> which is allocated in iommu_fwspec_init and called by iort_iommu_configure
>> for uefi.
> 
> You can look for a _DSM wherever it is convenient for you.  It could
> be in an AMBA shim layer.
> 
>> 2. Guest kernel also need support sva.
>> Using quirk, the guest can boot with sva enabled, since quirk is
>> self-contained by kernel.
>> If using  _DSM, a specific uefi or dtb has to be provided,
>> currently we can useQEMU_EFI.fd from apt install qemu-efi
> 
> I don't quite understand what this means, but as I mentioned before, a
> quirk for a *limited* number of devices is OK, as long as there is a
> plan that removes the need for a quirk for future devices.
> 
> E.g., if the next platform version ships with a DTB or firmware with a
> _DSM or other mechanism that enables the kernel to discover this
> information without a kernel change, it's fine to use a quirk to cover
> the early platform.
> 
> The principles are:
> 
>   - I don't want to have to update a quirk for every new Device ID
>     that needs this.

Hi Bjorn and Zhangfei,

We plan to use ATS/PRI to support SVA in future PCI devices. However, for
current devices, we need to add limited number of quirk to let them
work. The device IDs of current quirk needed devices are ZIP engine(0xa250, 0xa251),
SEC engine(0xa255, 0xa256), HPRE engine(0xa258, 0xa259), revision id are
0x21 and 0x30.

Let's continue to upstream these quirks!

Best,
Zhou

> 
>   - I don't really want to have to manage non-PCI information in the
>     struct pci_dev.  If this is AMBA- or IOMMU-related, it should be
>     stored in a structure related to AMBA or the IOMMU.
> .
>