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: <878rk1gb9g.ffs@tglx>
Date:   Wed, 23 Nov 2022 12:28:59 +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>
Subject: RE: [patch V2 02/33] genirq/msi: Provide struct msi_parent_ops

On Wed, Nov 23 2022 at 07:57, Kevin Tian wrote:
>> From: Thomas Gleixner <tglx@...utronix.de>
>> + * One solution is to let the root domain handle the initialization that's
>> + * why there is the @domain and the @msi_parent_domain pointer.
>  
> This is the part which I don't quite understand (sorry with limited knowledge
> in this area).
>
> In concept a hierarchical model has restrictions added up when moving
> down to lower layers i.e. presumably the root domain decides the minimal
> supported capabilities. In this case there is no need of a real parent pointer
> as long as every domain in the stack incrementally adds its restrictions to
> info->flags.
>
> I can see why this is required for x86 given that MULTI_MSI is supported
> only with IR. and we cannot make vector domain inclusively claiming
> MULTI_MSI since it's completely broken when the vector domain becomes
> the parent itself, in absence of IR.
>
> Just be curious whether this intermediate-parent-deciding-restrictions
> is generic instead of x86 specific, e.g. is it possible to have a 4-layers
> hierarchy where the root parent wants to check both two intermediate
> parents?

Sure. Nothing prevents you from doing so:

dom4:
    .init... = dom4_init

dom4_init()
    do_stuff()
    invoke parent init

dom3:
    .init... = parent_init

dom2:
    .init... = dom2_init

dom2_init()
    do_stuff()
    invoke parent init

....

See?

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ