netdev - Re: [RFC PATCH net-next 15/19] pds_vdpa: virtio bar setup for vdpa

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: <b8d4d9a3-16bf-699e-d09e-1d1deedfc8d5@amd.com>
Date:   Tue, 29 Nov 2022 15:02:56 -0800
From:   Shannon Nelson <shnelson@....com>
To:     Jason Wang <jasowang@...hat.com>,
        Shannon Nelson <snelson@...sando.io>, netdev@...r.kernel.org,
        davem@...emloft.net, kuba@...nel.org, mst@...hat.com,
        virtualization@...ts.linux-foundation.org
Cc:     drivers@...sando.io
Subject: Re: [RFC PATCH net-next 15/19] pds_vdpa: virtio bar setup for vdpa

On 11/21/22 10:36 PM, Jason Wang wrote:
> On Tue, Nov 22, 2022 at 11:32 AM Jason Wang <jasowang@...hat.com> wrote:
>> 在 2022/11/19 06:56, Shannon Nelson 写道:
>>> The PDS vDPA device has a virtio BAR for describing itself, and
>>> the pds_vdpa driver needs to access it.  Here we copy liberally
>>> from the existing drivers/virtio/virtio_pci_modern_dev.c as it
>>> has what we need, but we need to modify it so that it can work
>>> with our device id and so we can use our own DMA mask.
>>>
>>> We suspect there is room for discussion here about making the
>>> existing code a little more flexible, but we thought we'd at
>>> least start the discussion here.
>>
>>
>> Exactly, since the virtio_pci_modern_dev.c is a library, we could tweak
>> it to allow the caller to pass the device_id with the DMA mask. Then we
>> can avoid code/bug duplication here.

I'll look into possible mods for it, although I'm not sure how quickly I 
can get to that... maybe a v+1 along the way.

> 
> Btw, I found only isr/notification were used but not the others? If
> this is true, we can avoid mapping those capabilities.

I'll keep this in mind.

sln