Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 27 Jun 2023 12:49:34 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     "Tian, Kevin" <kevin.tian@intel.com>
Cc:     Robin Murphy <robin.murphy@arm.com>,
        Lu Baolu <baolu.lu@linux.intel.com>,
        Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
        Alex Williamson <alex.williamson@redhat.com>,
        Nicolin Chen <nicolinc@nvidia.com>,
        "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] iommu: Prevent RESV_DIRECT devices from blocking
 domains
Message-ID: <ZJsFDtU5Zao0iET4@nvidia.com>
References: <20230607035145.343698-1-baolu.lu@linux.intel.com>
 <20230607035145.343698-2-baolu.lu@linux.intel.com>
 <5d0d6665-93e4-f61f-d700-008c0fcb4a2f@arm.com>
 <ZJBbJHevOa8mAdll@nvidia.com>
 <0c1aec7a-8724-0f49-bccb-6025f5863bb7@arm.com>
 <ZJB0jyMQpZXWVANP@nvidia.com>
 <BN9PR11MB5276478406FDC2119A8EBD568C27A@BN9PR11MB5276.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BN9PR11MB5276478406FDC2119A8EBD568C27A@BN9PR11MB5276.namprd11.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?UWQZN8rLT/JbN/JQQkpWVXdj2Ji5bViG4J/p+M5JefmM+4IKxdC7fu55Ujxj?=
 =?us-ascii?Q?oppmbQiqx77KoJwymPAvMcJp/eP21TqPnF2SQ2Qm5l1XZTbkhGgtWaiob3di?=
 =?us-ascii?Q?kZUbPHLcLS1XYEptun9EIlEnzNGi0ZDg+zPT7t23045ODqg5EXRu6h4/0PWo?=
 =?us-ascii?Q?3DIfXUF6Spwvjdkg8yF7F8qRkbBcTa7dkB4YdUHX76MDhNis6mm/SX9L9i+V?=
 =?us-ascii?Q?4uOINrCzu+5Jj1kM/MxeIEUkPmmyNHE84407tnfbyr2aFVPKVk9QCUvW6Cgd?=
 =?us-ascii?Q?MVZ4Rg06O6E79BAjxnnr3F5VWf/7Prj2HSk0GBhQw9JmOFu5/fUBaV4rOVJo?=
 =?us-ascii?Q?ex//PIlVJuZMOzgE9qaEpxgjXnorFJIhbJmk+DFeqvNulA/yZHTK3T3QnlX0?=
 =?us-ascii?Q?9mfJfxJoWHFoEOP4mcydUfda0tx6FjLKpUG8gsEvj9bOImzwO9CTB3+tYWVG?=
 =?us-ascii?Q?YZfecjG0lZjBA42V+CwBsNiDUdCyGtPrHBImCztUuFIGx653J0CDs4hdmj50?=
 =?us-ascii?Q?RiGNxzL9Sxuou5xLJnlZckkjgOCFAvDrZErjRr0slEJsv4b5TN503IN8M3jB?=
 =?us-ascii?Q?H626cKfTcZg6EEPN0k9gTF6SNuT+HbVGB25Z1kZUBdL2y4S3r36rTHnMdjla?=
 =?us-ascii?Q?qr42uimXCyKnd72tEY338yN7ujAII2F5kABvJ4pZrG+P/nHCu/MwhGh7PjDm?=
 =?us-ascii?Q?JoeSD96wUg5mtyUzNQSfJF9NBFTA7ghH2W7n8WxAEAdzi+akCGCadDdOOuYF?=
 =?us-ascii?Q?J3qlj+JHDi4GGo6uUSdMjcIhcschoyK3Zlaxy3QQUPMa3sgOLHgm6ROY477Z?=
 =?us-ascii?Q?sHJLWZ9U6JE5qQvMUgxNMBOaZ5SF9n/tUU/sXVqkWv533m2xnrvnQkDJnuNv?=
 =?us-ascii?Q?eTwsJDKh4ZlDfGrnFrPd/nVygNEy3e73v35sLdJaOg/BwZAsjTEW/zDMIGL3?=
 =?us-ascii?Q?0E1R4pJ78noBxVQnLOMo8PM8NMAUxYVNqhCZ8QzoB76mOhogEwxgkzMv+Zhe?=
 =?us-ascii?Q?ufWdvcIQ9MiJbF6oXbH4owLgs0zq2SRWGYzi4Cnt4nH0mXblbb8qd+tGujay?=
 =?us-ascii?Q?KeDTje6AUhdgDo0lZVvWun5eo3eOxxfCLoonXfA8veH+1/4cSy5EmNik6A3W?=
 =?us-ascii?Q?XaQBqIHQTPGoLbL2jxURMINhfllHGHHNdEhubi/2J1YZrXkqCWjSvh1X/DFs?=
 =?us-ascii?Q?76P13pGUw98Xccgx9dhWami7gxVaXWaayBZ5vLqxtpOlGdl2E6J4255Yvp/3?=
 =?us-ascii?Q?gsGy8HboSy0DtwIPpUfdMyJt8LIOpZSDs4QqYlgtMVTUpRmcXfEYpKFHzXie?=
 =?us-ascii?Q?70skli+d9A5j4eVVP+ylcU1qmSWGJZ1xrE9sSa6h2L0hdiAhePNRHkkBZTD0?=
 =?us-ascii?Q?kmocIlpxMWo+w+N/ChAI9y2Fv87xQBlAuDwo02Fo+rz3dz7rNF9zB2lGggLA?=
 =?us-ascii?Q?l+DFhnLTdTjJdP5IfNlOYgG3EwQ7DOXpenjYE/fl+nKPv8imQtj9NVgRV6M5?=
 =?us-ascii?Q?L9MCrgmQ+IF/bMARWedFc2J+W4RsLLIpClOf7m28CwuX5S5M7QGe9K9AMZpT?=
 =?us-ascii?Q?UFANr+bPeDd6Fvfvv6mlCxWyVHBcJrt5zJJY+v1O?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 995837e1-7023-4b1e-aef1-08db77261b96
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2023 15:49:35.9814
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: JhWg1aI51NH8+TleAkXTxq7YPY6XSZ08jOMv9gkADgRmRux/NduIx7yBP9isYWnN
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB8812
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jun 27, 2023 at 08:10:48AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Monday, June 19, 2023 11:30 PM
> > 
> > On Mon, Jun 19, 2023 at 03:20:30PM +0100, Robin Murphy wrote:
> > 
> > > so if the only time they're used is when the IOMMU driver has
> > > already had a catastrophic internal failure such that we decide to
> > > declare the device toasted and deliberately put it into an unusable
> > > state, blocking its reserved regions doesn't seem like a big deal.
> > 
> > I think we should discuss then when we get to actually implementing
> > the error recovery flow we want. I do like blocking in general for the
> > reasons you give, and that was my first plan.. But if the BIOS will
> > crash or something if we don't do the reserved region maps that isn't
> > so good either. IDK would like to hear from the people using this BIOS
> > feature.
> > 
> 
> The only devices with RMRR which I'm aware of on Intel platforms are
> GPU and USB. However they are all RESV_DIRECT_RELAXABLE type.
> 
> Here is one reference from the Xen hypervisor. It has a concept called
> quarantine domain (similar to blocking domain) when a device is
> de-assigned w/o an owner. The quarantine domain has no mappings
> except the ones identity-mapped for RMRR types. I'm not sure whether
> they observed real examples of RMRR devices which are not GPU/USB.

I guess, it seems a bit hard core, but we could spend the cost to
build such a domain during probe..

At least for our cases we already do expect that DMA is halted before
we start messing with the domains so identity may not be the same
issue as with Xen..

Jason