netdev - Re: [PATCH 3/5] vDPA: introduce vDPA bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2a324cec-2863-58f4-c58a-2414ee32c930@redhat.com>
Date:   Tue, 21 Jan 2020 12:00:57 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Jason Gunthorpe <jgg@...lanox.com>
Cc:     Shahaf Shuler <shahafs@...lanox.com>,
        Rob Miller <rob.miller@...adcom.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>,
        Netdev <netdev@...r.kernel.org>,
        "Bie, Tiwei" <tiwei.bie@...el.com>,
        "maxime.coquelin@...hat.com" <maxime.coquelin@...hat.com>,
        "Liang, Cunming" <cunming.liang@...el.com>,
        "Wang, Zhihong" <zhihong.wang@...el.com>,
        "Wang, Xiao W" <xiao.w.wang@...el.com>,
        "haotian.wang@...ive.com" <haotian.wang@...ive.com>,
        "Zhu, Lingshan" <lingshan.zhu@...el.com>,
        "eperezma@...hat.com" <eperezma@...hat.com>,
        "lulu@...hat.com" <lulu@...hat.com>,
        Parav Pandit <parav@...lanox.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        "stefanha@...hat.com" <stefanha@...hat.com>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "hch@...radead.org" <hch@...radead.org>,
        Ariel Adam <aadam@...hat.com>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...lanox.com>,
        "hanand@...inx.com" <hanand@...inx.com>,
        "mhabets@...arflare.com" <mhabets@...arflare.com>
Subject: Re: [PATCH 3/5] vDPA: introduce vDPA bus


On 2020/1/21 上午1:49, Jason Gunthorpe wrote:
> On Mon, Jan 20, 2020 at 04:43:53PM +0800, Jason Wang wrote:
>> This is similar to the design of platform IOMMU part of vhost-vdpa. We
>> decide to send diffs to platform IOMMU there. If it's ok to do that in
>> driver, we can replace set_map with incremental API like map()/unmap().
>>
>> Then driver need to maintain rbtree itself.
> I think we really need to see two modes, one where there is a fixed
> translation without dynamic vIOMMU driven changes and one that
> supports vIOMMU.


I think in this case, you meant the method proposed by Shahaf that sends 
diffs of "fixed translation" to device?

It would be kind of tricky to deal with the following case for example:

old map [4G, 16G) new map [4G, 8G)

If we do

1) flush [4G, 16G)
2) add [4G, 8G)

There could be a window between 1) and 2).

It requires the IOMMU that can do

1) remove [8G, 16G)
2) flush [8G, 16G)
3) change [4G, 8G)

....

>
> There are different optimization goals in the drivers for these two
> configurations.
>
>>> If the first one, then I think memory hotplug is a heavy flow
>>> regardless. Do you think the extra cycles for the tree traverse
>>> will be visible in any way?
>> I think if the driver can pause the DMA during the time for setting up new
>> mapping, it should be fine.
> This is very tricky for any driver if the mapping change hits the
> virtio rings. :(
>
> Even a IOMMU using driver is going to have problems with that..
>
> Jason


Or I wonder whether ATS/PRI can help here. E.g during I/O page fault, 
driver/device can wait for the new mapping to be set and then replay the 
DMA.

Thanks

>