From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D242EC48BDF for ; Fri, 18 Jun 2021 13:47:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AA99D613EC for ; Fri, 18 Jun 2021 13:47:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234012AbhFRNuD (ORCPT ); Fri, 18 Jun 2021 09:50:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233615AbhFRNuD (ORCPT ); Fri, 18 Jun 2021 09:50:03 -0400 Received: from theia.8bytes.org (8bytes.org [IPv6:2a01:238:4383:600:38bc:a715:4b6d:a889]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DCCA0C061574; Fri, 18 Jun 2021 06:47:53 -0700 (PDT) Received: by theia.8bytes.org (Postfix, from userid 1000) id 6801E3A7; Fri, 18 Jun 2021 15:47:52 +0200 (CEST) Date: Fri, 18 Jun 2021 15:47:51 +0200 From: Joerg Roedel To: "Tian, Kevin" Cc: Alex Williamson , Jason Gunthorpe , Jean-Philippe Brucker , David Gibson , Jason Wang , "parav@mellanox.com" , "Enrico Weigelt, metux IT consult" , Paolo Bonzini , Shenming Lu , Eric Auger , Jonathan Corbet , "Raj, Ashok" , "Liu, Yi L" , "Wu, Hao" , "Jiang, Dave" , Jacob Pan , Kirti Wankhede , Robin Murphy , "kvm@vger.kernel.org" , "iommu@lists.linux-foundation.org" , David Woodhouse , LKML , Lu Baolu Subject: Re: Plan for /dev/ioasid RFC v2 Message-ID: References: <20210611133828.6c6e8b29.alex.williamson@redhat.com> <20210612012846.GC1002214@nvidia.com> <20210612105711.7ac68c83.alex.williamson@redhat.com> <20210614140711.GI1002214@nvidia.com> <20210614102814.43ada8df.alex.williamson@redhat.com> <20210615101215.4ba67c86.alex.williamson@redhat.com> <20210616133937.59050e1a.alex.williamson@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Kevin, On Thu, Jun 17, 2021 at 07:31:03AM +0000, Tian, Kevin wrote: > Now let's talk about the new IOMMU behavior: > > - A device is blocked from doing DMA to any resource outside of > its group when it's probed by the IOMMU driver. This could be a > special state w/o attaching to any domain, or a new special domain > type which differentiates it from existing domain types (identity, > dma, or unmanged). Actually existing code already includes a > IOMMU_DOMAIN_BLOCKED type but nobody uses it. There is a reason for the default domain to exist: Devices which require RMRR mappings to be present. You can't just block all DMA from devices until a driver takes over, we put much effort into making sure there is not even a small window in time where RMRR regions (unity mapped regions on AMD) are not mapped. And if a device has no RMRR regions defined, then the default domain will be identical to a blocking domain. Device driver bugs don't count here, as they can be fixed. The kernel trusts itself, so we can rely on drivers unmapping all of their DMA buffers. Maybe that should be checked by dma-debug to find violations there. Regards, Joerg