On Wed, Sep 21, 2022 at 07:57:00AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > 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. This includes any pPASIDs and MSI routing. > btw isn't it the same reason why we don't want to expose host > PASID into guest in iommufd discussion? Not quite, the only reason not to expose the physical pasid is ENQCMD and other mdev based approaches. If IMS is being used with a mdev then perhaps the mdev driver can do the vIMS/pIMS translation much like we want to do for pPASID/vPASID But if a RID is being used with IMS then the MSI under the RID should be stable, IMHO. Jason
