netdev - Re: [PATCH V2 mlx5-next 12/14] vfio/mlx5: Implement vfio

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20211029002637.GS2744544@nvidia.com>
Date:   Thu, 28 Oct 2021 21:26:37 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Cornelia Huck <cohuck@...hat.com>
Cc:     Alex Williamson <alex.williamson@...hat.com>,
        Yishai Hadas <yishaih@...dia.com>, bhelgaas@...gle.com,
        saeedm@...dia.com, linux-pci@...r.kernel.org, kvm@...r.kernel.org,
        netdev@...r.kernel.org, kuba@...nel.org, leonro@...dia.com,
        kwankhede@...dia.com, mgurtovoy@...dia.com, maorg@...dia.com,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>
Subject: Re: [PATCH V2 mlx5-next 12/14] vfio/mlx5: Implement vfio_pci driver
 for mlx5 devices

On Thu, Oct 28, 2021 at 05:08:11PM +0200, Cornelia Huck wrote:

> that should go in right now. Actually, I'd already consider it too late
> even if we agreed now; I would expect a change like this to get at least
> two weeks in linux-next before the merge window.

Usually linux-next is about sorting out integration problems so we
have an orderly merge window. Nobody is going to test this code just
because it is in linux-next, it isn't mm or something with coverage
there.

> > Yes, if qemu becomes deployed, but our testing shows qemu support
> > needs a lot of work before it is deployable, so that doesn't seem to
> > be an immediate risk.
> 
> Do you have any patches/problem reports you can share?

Yishai has some stuff, he was doing failure injection testing and
other interesting things. I think we are hoping to start looking at
it.

> If you already identified that there is work to be done in QEMU, I think
> that speaks even more for delaying this. What if we notice that uapi
> changes are needed while fixing QEMU?

I don't think it is those kinds of bugs.

Jason