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: <8735a9e3xo.ffs@tglx>
Date:   Wed, 23 Nov 2022 22:50:11 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Tian, Kevin" <kevin.tian@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     "x86@...nel.org" <x86@...nel.org>, Joerg Roedel <joro@...tes.org>,
        Will Deacon <will@...nel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Marc Zyngier <maz@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jason Gunthorpe <jgg@...lanox.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        Logan Gunthorpe <logang@...tatee.com>,
        "Raj, Ashok" <ashok.raj@...el.com>, Jon Mason <jdmason@...zu.us>,
        Allen Hubbe <allenbh@...il.com>,
        "Ahmed S. Darwish" <darwi@...utronix.de>
Subject: RE: [patch V2 12/33] PCI/MSI: Add support for per device MSI[X]
 domains

On Wed, Nov 23 2022 at 12:41, Thomas Gleixner wrote:
> On Wed, Nov 23 2022 at 08:08, Kevin Tian wrote:
>>> +bool pci_setup_msi_device_domain(struct pci_dev *pdev)
>>> +{
>>> +	if (WARN_ON_ONCE(pdev->msix_enabled))
>>> +		return false;
>>
>> the check already exists in __pci_enable_msi_range()
>>
>>> +bool pci_setup_msix_device_domain(struct pci_dev *pdev, unsigned int
>>> hwsize)
>>> +{
>>> +	if (WARN_ON_ONCE(pdev->msix_enabled))
>>> +		return false;
>>
>> ditto.
>>
>> btw according to the comment this should check pdev->msi_enabled.
>
> Yeah, those are probably redundant.

I fixed the MSIX check and kept them for paranoia reasons, so changes in
the calling code get caught.

>> This is general PCI MSI logic. So an open related to my rely to patch02,
>> is it correct for PCI core to assume that the real parent imposes all the
>> restrictions and there is no need to further go down the hierarchy?
>
> That was my working assumption and it turned out to be correct with both
> x86 and ARM.

As a follow up, I went through some of the other architectures,
especially the places which have extra limitations and it turns out that
the restriction comes always from the direct parent.

If that ever changes then we need a callback which lets us evaluate the
resulting capabilities through the hierarchy. That's nothing which can
be evaluated directly.

Just look at the x86 hierarchy with IR. IR allows multi PCI-MSI, but the
vector domain does not. Who is right? That's a decision which is made in
the particular hierarchy.

For now it's valid that the direct MSI parent has the proper set
available.

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ