Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC PATCH 0/7] Untrusted device support for virtio
To:     Christoph Hellwig <hch@infradead.org>
Cc:     mst@redhat.com, virtualization@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, xieyongji@bytedance.com,
        stefanha@redhat.com, file@sect.tu-berlin.de, ashish.kalra@amd.com,
        martin.radev@aisec.fraunhofer.de, konrad.wilk@oracle.com,
        kvm@vger.kernel.org
References: <20210421032117.5177-1-jasowang@redhat.com>
 <20210422063128.GB4176641@infradead.org>
From:   Jason Wang <jasowang@redhat.com>
Message-ID: <0c61dcbb-ac5b-9815-a4a1-5f93ae640011@redhat.com>
Date:   Thu, 22 Apr 2021 16:19:16 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.9.1
MIME-Version: 1.0
In-Reply-To: <20210422063128.GB4176641@infradead.org>
Content-Type: text/plain; charset=gbk; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


?? 2021/4/22 ????2:31, Christoph Hellwig д??:
> On Wed, Apr 21, 2021 at 11:21:10AM +0800, Jason Wang wrote:
>> The behaivor for non DMA API is kept for minimizing the performance
>> impact.
> NAK.  Everyone should be using the DMA API in a modern world.  So
> treating the DMA API path worse than the broken legacy path does not
> make any sense whatsoever.


I think the goal is not treat DMA API path worse than legacy. The issue 
is that the management layer should guarantee that ACCESS_PLATFORM is 
set so DMA API is guaranteed to be used by the driver. So I'm not sure 
how much value we can gain from trying to 'fix' the legacy path. But I 
can change the behavior of legacy path to match DMA API path.

Thanks