From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753941AbdLHNs2 (ORCPT ); Fri, 8 Dec 2017 08:48:28 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:38942 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753773AbdLHNsZ (ORCPT ); Fri, 8 Dec 2017 08:48:25 -0500 Subject: Re: [PATCH v3 15/16] iommu: introduce page response function To: Jacob Pan Cc: "iommu@lists.linux-foundation.org" , LKML , Joerg Roedel , David Woodhouse , Greg Kroah-Hartman , Rafael Wysocki , Alex Williamson , Lan Tianyu , Jean Delvare , Will Deacon , "Kumar, Sanjay K" References: <1510944914-54430-1-git-send-email-jacob.jun.pan@linux.intel.com> <1510944914-54430-16-git-send-email-jacob.jun.pan@linux.intel.com> <93661c1c-2d3b-295f-0b9d-52e50ea9e1d0@arm.com> <20171204133715.50c45136@jacob-builder> <20171206112521.1edf8e9b@jacob-builder> <39fcbbd2-2e6a-f05a-8cb4-8e3ad4ead369@arm.com> <20171207171733.5e62bcf7@jacob-builder> From: Jean-Philippe Brucker Message-ID: <8873d7e9-8857-90af-73f2-f3e60ac9e15d@arm.com> Date: Fri, 8 Dec 2017 13:51:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171207171733.5e62bcf7@jacob-builder> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/12/17 01:17, Jacob Pan wrote: [...] >> Sounds good. Timeout seems a bit complicated to implement (and how do >> we guess what timeout would work?), so maybe it's simpler to enforce >> a quota of outstanding faults per VM, for example half of the shared >> queue size (the number can be chosen by the IOMMU driver). If a VM >> has that many outstanding faults, then any new fault is immediately >> terminated by the host. A bit rough but it might be enough to >> mitigate the problem initially, and we can always tweak it later (for >> instance disable faulting if a guest doesn't ever reply). >> > I have to make a correction/clarification, even though vt-d has a per > iommu shared queue for prq but we do not stall. Ashok reminded me that. > So there is no constraint on IOMMU if one of the guests does not > respond. All the pressure is on the device which may have limited # of > pending PR. Right that makes more sense, for PRI the IOMMU doesn't need to keep page request state internally. Then it seems the problem only exists for Stall and someone's going to have a fun time working around it in the SMMU driver :( >> Seems like VFIO should enforce this quota, since the IOMMU layer >> doesn't know which device is assigned to which VM. If it's the IOMMU >> that enforces quotas per device and a VM has 15 devices assigned, >> then the guest can still DoS the IOMMU. >> > I still think timeout makes more sense than quota in that a VM could > be under quota but failed to respond to one of the devices forever. > I agree it is hard to devise a good timeout limit but since this is to > prevent rare faults, we could pick a relatively large timeout. And we > only tracks the longest pending timeout per device. The error condition > we try to prevent is not necessarily only stall buffer overflow but > timeout also, right? Handling timeouts is less crucial than making sure a guest doesn't monopolize all the shared resources, in my opinion. If a guest can't reply to the injected faults, it's not really our problem as long as it doesn't affect fault injection for other guests. We can reset the device and clean pending faults when the guest terminates or resets the device. I guess it's similar to IRQ injection, you don't care if the guest acknowledges your interrupt or not as long as you make sure it is delivered. Thanks, Jean