On Tue, Feb 18, 2025 at 06:17:15PM +0000, Pranjal Shrivastava wrote: > On Tue, Feb 18, 2025 at 05:24:08AM +0000, Tian, Kevin wrote: > > > From: Nicolin Chen <nicol...@nvidia.com> > > > Sent: Saturday, January 25, 2025 8:31 AM > > > > > > There is a DoS concern on the shared hardware event queue among devices > > > passed through to VMs, that too many translation failures that belong to > > > VMs could overflow the shared hardware event queue if those VMs or their > > > VMMs don't handle/recover the devices properly. > > > > This statement is not specific to the nested configuration. > > > > > > > > The MEV bit in the STE allows to configure the SMMU HW to merge similar > > > event records, though there is no guarantee. Set it in a nested STE for > > > DoS mitigations. > > > > Is MEV available only in nested mode? Otherwise it perhaps makes > > sense to turn it on in all configurations in IOMMUFD paths... > > MEV is available at all times (if an implemented by the HW) and doesn't > depend on the nested mode. As per the Arm SMMUv3 spec (section 3.5.5): > > Events can be merged where all of the following conditions are upheld: > - The event types and all fields are identical, except fields explicitly > indicated in section 7.3 Event records. > > - If present, the Stall field is 0. Stall fault records are not merged. > > I'm not sure to what extent, but I think *trying* to merge similar event > should reduce some chances of overflowing the hw eventq. > > > Is MEV available only in nested mode? Otherwise it perhaps makes > > sense to turn it on in all configurations in IOMMUFD paths... > > I think the arm-smmu-v3's iommufd implementation only supports nested > which could be the reason.
I guess what Kevin says is that non-nested STE should set the MEV as well, e.g. BYPASS and ABORT, and perhaps stage-1-only case too where the attaching domain = UNMANAGED. Thanks Nicolin
