On Fri, Nov 08, 2024 at 02:53:22PM +0000, Will Deacon wrote: > So, given where we are in the cycle, I think the pragmatic thing to do > is to land this change now and enable the ongoing IOMMUFD work to > continue. We still have over two months to resolve any major problems > with the interface (and even unplug it entirely from the driver if we > really get stuck) but for now I think it's "fine". Thanks Will, this all eloquently captures my line of reasoning also. I will add that after going through the exercise with Nicolin, to write down all the fields the VMM is allowed to touch, it seems we do have a list of future fields that likely do not require any host support (E0PD, AIE, PBHA, D128, DS). We also have ones that will (BTM) and then the fwspec weirdo of HTTU. Given those ratios I feel pretty good about showing that data to the userspace, expecting that down the road we will "turn it on" for E0PD/etc without any kernel change, and BTM/HTTU will not use idr for discovery. The biggest risk is the VMM's badly muck it up. I now think it was a lazy shortcut to not enumerate all the fields in the kdoc. Now that we've done that we see that the (unreviewed) RFC qemu patches did miss some things and it is being corrected. Nicolin and I had some discussion if we should go ahead and include E0PD/etc in the documentation right now, but we both felt some uncertainty that we really understood those features deeply enough to be confident, and have no way to test. There is also the nanny option of zeroing everything not in the approved list, but I feel like it is already so hard to write a VMM vSMMU3 that is too nannyish. Hoepfully time will not show that my opinion of VMM authors is too high. :\ Jason
