Re: [PATCH V2 mlx5-next 12/14] vfio/mlx5: Implement vfio_pci driver for mlx5 devices

From: Yishai Hadas <yishaih@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>, Cornelia Huck <cohuck@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	<bhelgaas@google.com>, <saeedm@nvidia.com>,
	<linux-pci@vger.kernel.org>, <kvm@vger.kernel.org>,
	<netdev@vger.kernel.org>, <kuba@kernel.org>, <leonro@nvidia.com>,
	<kwankhede@nvidia.com>, <mgurtovoy@nvidia.com>,
	<maorg@nvidia.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH V2 mlx5-next 12/14] vfio/mlx5: Implement vfio_pci driver for mlx5 devices
Date: Fri, 29 Oct 2021 10:35:28 +0300	[thread overview]
Message-ID: <6334b789-e619-9208-38d2-c6ba5429f830@nvidia.com> (raw)
In-Reply-To: <20211029002637.GS2744544@nvidia.com>

On 10/29/2021 3:26 AM, Jason Gunthorpe wrote:
> 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.

Right, in addition, the series has been on-list over a month to let 
people review and comment.

V5 has no specific comment on, I believe that we are in a good state / 
point to move forward with it.

>>> 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.

Correct, I encountered some SF of QEMU upon failure injection / error flows.

For example,

- Unbinding the VF then trying to run savevm.

- Moving the mlx5 device to ERROR state, my expectation was to see some 
recovery flow from QEMU as of calling the RESET ioctl to let it be 
running again, however it crashed.

- etc.

Yes, we have some plans to start looking at.

>> 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.

Right, it doesn't seem as uapi changed are required, need to debug and 
fix QEMU.

Yishai