On 6/2/21 1:37 PM, Luck, Tony wrote: >>> ... so on a PASID system, your trivial reproducer would theoretically >>> fire the same way and corrupt FPU state just as well. >> >> This is worse and you can't selftest it because the IPI can just hit in >> the middle of _any_ FPU state operation and corrupt state. > > That sounds like we should abandon the "IPI all the other threads > to force enable the PASID for them" approach. It would just be a > nightmare of papering over cracks when the IPI was delivered at > some inconvenient moment when the recipient was in the middle > of touching xsave state. > > I've told Fenghua to dig out the previous iteration of this patch where > the plan was to lazily fix the PASID_MSR in other threads in the #GP > handler.
Blech. Also this won't work for other PASID-like features. I have a half-written patch to fix this up for real. Stay tuned. > Seems like a better direction than trying to fix the IPI method. The > virtualization > folks will like this way more because IPI in guest causes a couple of VMEXIT > so is somewhat expensive. It happens at most once per PASID-using process. _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
