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: <BN9PR11MB5276CAB439EE27557FC17B1A8C4F9@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Wed, 21 Sep 2022 07:57: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: 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.

btw isn't it the same reason why we don't want to expose host
PASID into guest in iommufd discussion?

My overall impression is that any such exposure of host resource
requires certain guest cooperation to do after-the-fact fix to
enable migration (though it's obviously difficult for this interrupt
case), otherwise the actual usage would be very limited...