Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [PATCH v1 14/14] iommu/arm-smmu-v3: Add arm_smmu_cache_invalidate_user | Date | Fri, 24 Mar 2023 09:02:34 +0000 |
| |
> From: Nicolin Chen <nicolinc@nvidia.com> > Sent: Wednesday, March 22, 2023 2:42 PM > > On Tue, Mar 21, 2023 at 08:48:31AM -0300, Jason Gunthorpe wrote: > > On Tue, Mar 21, 2023 at 08:34:00AM +0000, Tian, Kevin wrote: > > > > > > > Rephrasing that to put into a design: the IOCTL would pass a > > > > > user pointer to the queue, the size of the queue, then a head > > > > > pointer and a tail pointer? Then the kernel reads out all the > > > > > commands between the head and the tail and handles all those > > > > > invalidation commands only? > > > > > > > > Yes, that is one possible design > > > > > > If we cannot have the short path in the kernel then I'm not sure the > > > value of using native format and queue in the uAPI. Batching can > > > be enabled over any format. > > > > SMMUv3 will have a hardware short path where the HW itself runs the > > VM's command queue and does this logic. > > > > So I like the symmetry of the SW path being close to that. > > A tricky thing here that I just realized: > > With VCMDQ, the guest will have two CMDQs. One is the vSMMU's > CMDQ handling all non-TLBI commands like CMD_CFGI_STE via the > invalidation IOCTL, and the other hardware accelerated VCMDQ > handling all TLBI commands by the HW. In this setup, we will > need a VCMDQ kernel driver to dispatch commands into the two > different queues. >
why doesn't hw generate a vm-exit for unsupported CMDs in VCMDQ and then let them emulated by vSMMU? such events should be rare once map/unmap are being conducted...
| |