linux-kernel - RE: [patch 21/32] NTB/msi: Convert to msi_on_each

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: <BN9PR11MB52768936DF8C7F19D5997A0C8C4E9@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Thu, 22 Sep 2022 05:11:00 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        "Chatre, Reinette" <reinette.chatre@...el.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "Logan Gunthorpe" <logang@...tatee.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "Bjorn Helgaas" <helgaas@...nel.org>,
        Marc Zygnier <maz@...nel.org>,
        Alex Williamson <alex.williamson@...hat.com>,
        "Dey, Megha" <megha.dey@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jon Mason <jdmason@...zu.us>, Allen Hubbe <allenbh@...il.com>,
        "linux-ntb@...glegroups.com" <linux-ntb@...glegroups.com>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        "x86@...nel.org" <x86@...nel.org>, "Rodel, Jorg" <jroedel@...e.de>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>
Subject: RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Wednesday, September 21, 2022 8:48 PM
> 
> On Wed, Sep 21, 2022 at 07:57:00AM +0000, Tian, Kevin wrote:
> > > From: Jason Gunthorpe <jgg@...dia.com>
> > > Sent: Tuesday, September 20, 2022 10:10 PM
> > >
> > > On Thu, Sep 15, 2022 at 09:24:07AM +0000, Tian, Kevin wrote:
> > >
> > > > After migration the IRTE index could change hence the addr/data pair
> > > > acquired before migration becomes stale and must be fixed.
> > >
> > > The migration has to keep this stuff stable somehow, it seems
> > > infeasible to fix it after the fact.
> > >
> >
> > This is not how live migration typically works, i.e. we don't try to
> > freeze the same host resource cross migration. It's pretty fragile
> > and the chance of failure is high.
> 
> Thinking of the interrupt routing as a host resource is the problem -
> it is a device resource and just like PASID the ideal design would
> have each RID have its own stable numberspace scoped within it. The
> entire RID and all its stable numberspace would be copied over.
> 

Unfortunately it is not the case at least on Intel VT-d. The interrupt
remapping table is per VT-d instead of per RID.