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=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 1E97AC47094 for ; Tue, 8 Jun 2021 01:00:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0236361059 for ; Tue, 8 Jun 2021 01:00:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230494AbhFHBCW (ORCPT ); Mon, 7 Jun 2021 21:02:22 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:41105 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230209AbhFHBCV (ORCPT ); Mon, 7 Jun 2021 21:02:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623114029; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l9Hxnp9TzX1Qa0LPCbDI+r/Swgm1W5T0HqpzgDaMsIM=; b=cJCSUgDFNaKbpGVyueCsW9AsPJ87rUUNJ2uMBjgxXT2QJvdiZBdYfxXHP3+/3p6nGYzEWg tmD9Sw/ctpoL8CGN2Jao+RWPj6m+4UmOTw2ch+nQomfNLK+jYu4/ul7/uLSGdM5FMIH/GF Uck9AV0RXzwXaKJm07iuCruZvckdEOY= Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-229-ZtjKPfJSM66UnieZPUkJUg-1; Mon, 07 Jun 2021 21:00:28 -0400 X-MC-Unique: ZtjKPfJSM66UnieZPUkJUg-1 Received: by mail-pj1-f72.google.com with SMTP id 15-20020a17090a0f0fb029016ad0f32fd0so11810033pjy.6 for ; Mon, 07 Jun 2021 18:00:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=l9Hxnp9TzX1Qa0LPCbDI+r/Swgm1W5T0HqpzgDaMsIM=; b=F1kuMFNQzelmtDQs9DAj1UVyrwMyKaS4XfeVWUIRMrK9BdnvBul4sPEawjrHK7PTS9 P//BqPU3D/10CdwY7vxCk97EPydBKbrYrPt/YQM/K90d/xaq7740QjxvanotRdlz8I4I M5bPMwd2EQVSzYnRbuFR2H1UGvGNK6p3tIUrzRbDqx3WOiWxiERVB2NQkvjKZIFiedQk OKCXglKpZgNbF0ViuADnSt4AqSHqHgKB4bb06PoljMPIE2fLfF0uOGZKJuwtXvfVQgpI ZDZW0RmePnyuejSuSvCFWDOnsjuuQRY2NeFou2KeHxGYKTqJZheKw/t9tUGYEycTrtQv L6Fw== X-Gm-Message-State: AOAM533FMmy4RZYsdbM5KwPAU2v6GVSkmCIiAwmS1LAidyN3DCU0GW4Y Pdu/xbeHo5UPr5mUImMTFUGtQRMcUbQvu9p28L2z0mX9U2csqXHrPBxElKZijtzpmLag3RwmHt3 TjND8+xmeV5/R4P1Za5HRl1UW X-Received: by 2002:a17:90a:db0f:: with SMTP id g15mr1973146pjv.156.1623114026999; Mon, 07 Jun 2021 18:00:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYWbmdIHR4JeIkPyMKnrD47V0fE4/gLC34oE2C1BXzJ6Yk+6wQV2cQXaOEH+lTIww5tPr8Pg== X-Received: by 2002:a17:90a:db0f:: with SMTP id g15mr1973123pjv.156.1623114026742; Mon, 07 Jun 2021 18:00:26 -0700 (PDT) Received: from wangxiaodeMacBook-Air.local ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id w142sm9258485pff.154.2021.06.07.18.00.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Jun 2021 18:00:26 -0700 (PDT) Subject: Re: [RFC] /dev/ioasid uAPI proposal To: Jason Gunthorpe Cc: Alex Williamson , "Tian, Kevin" , Jean-Philippe Brucker , "Jiang, Dave" , "Raj, Ashok" , "kvm@vger.kernel.org" , Jonathan Corbet , Robin Murphy , LKML , "iommu@lists.linux-foundation.org" , David Gibson , Kirti Wankhede , David Woodhouse , Gerd Hoffmann References: <20210602120111.5e5bcf93.alex.williamson@redhat.com> <20210602180925.GH1002214@nvidia.com> <20210602130053.615db578.alex.williamson@redhat.com> <20210602195404.GI1002214@nvidia.com> <20210602143734.72fb4fa4.alex.williamson@redhat.com> <6a9426d7-ed55-e006-9c4c-6b7c78142e39@redhat.com> <20210603130927.GZ1002214@nvidia.com> <65614634-1db4-7119-1a90-64ba5c6e9042@redhat.com> <20210604115805.GG1002214@nvidia.com> <895671cc-5ef8-bc1a-734c-e9e2fdf03652@redhat.com> <20210607141424.GF1002214@nvidia.com> From: Jason Wang Message-ID: <1cf9651a-b8ee-11f1-1f70-db3492a76400@redhat.com> Date: Tue, 8 Jun 2021 09:00:15 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210607141424.GF1002214@nvidia.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ÔÚ 2021/6/7 ÏÂÎç10:14, Jason Gunthorpe дµÀ: > On Mon, Jun 07, 2021 at 11:18:33AM +0800, Jason Wang wrote: > >> Note that no drivers call these things doesn't meant it was not >> supported by the spec. > Of course it does. If the spec doesn't define exactly when the driver > should call the cache flushes for no-snoop transactions then the > protocol doesn't support no-soop. Just to make sure we are in the same page. What I meant is, if the DMA behavior like (no-snoop) is device specific. There's no need to mandate a virtio general attributes. We can describe it per device. The devices implemented in the current spec does not use non-coherent DMA doesn't mean any future devices won't do that. The driver could choose to use transport (e.g PCI), platform (ACPI) or device specific (general virtio command) way to detect and flush cache when necessary. > > no-snoop is only used in very specific sequences of operations, like > certain GPU usages, because regaining coherence on x86 is incredibly > expensive. > > ie I wouldn't ever expect a NIC to use no-snoop because NIC's expect > packets to be processed by the CPU. For NIC yes. But virtio is more that just NIC. We've already supported GPU and crypto devices. In this case, no-snoop will be useful since the data is not necessarily expected to be processed by CPU. And a lot of other type of devices are being proposed. Thanks > > "non-coherent DMA" is some general euphemism that evokes images of > embedded platforms that don't have coherent DMA at all and have low > cost ways to regain coherence. This is not at all what we are talking > about here at all. > > Jason >