RE: [PATCH v2] Add device reset timeout field

[Cornelia Huck <cohuck@redhat.com>]

On Mon, Oct 11 2021, Parav Pandit <parav@nvidia.com> wrote:

>> From: Cornelia Huck <cohuck@redhat.com>
>> Sent: Monday, October 11, 2021 8:29 PM
>> 
>> On Mon, Oct 11 2021, Parav Pandit <parav@nvidia.com> wrote:

>> > I think read only device reset timeout is most elegant option during device
>> initialization phase that eliminates infinite loop of today.
>> 
>> Why can't a driver just go ahead and do a timeout regardless? 
> o.k. lets consider this thought exercise. What is the timeout value that driver will choose if device doesn't specify one?
> I explained in previous thread and you acked that actual fw based device may take longer to initialize than pure sw implementation backend.
> In second example a pre-boot device can take even longer initialization time.
> Sriov VF device may initialize lot faster.
> Instead of driver having such transport, and device specific checks, (or some very short or very long timeout), we propose, that let device mention such timeout value.

But does the driver really care in all cases? Say, I'm a virtio-blk
driver, and I drive all kinds of virtio-blk devices. If I choose a
timeout value that accommodates hardware devices, software devices will
just always breeze past, and nothing bad happens. If I know that I'm in
a pre-boot environment, I'll just add on a value that allows devices to
warm up. I'd say reasonable values depend way more on the driver
implementation and the environment it is running in than on the device.

>
>> This seems
>> pretty much to depend on the implementation. Nothing in the virtio spec forces
>> the driver to reset all devices serially and wait potentially forever. (If you deal
>> with a large amount of subdevices you cannot access concurrently, you likely
>> already have problems.)
> Sure, nothing in driver forces serial initialization.
> However in reality, PCI device scanning on the bus in hotplug driver, preboot env, sriov vf initialization is serial.

So, can't pci scan asynchronously? Is that a limitation in the pci spec?
The Linux ccw bus switched to asynchronous processing precisely because
of slow devices years ago, FWIW, so that may be why I don't really
understand the issue.

> In preboot case, even the order is defined, so it is sort of serial.

Again, is that somewhere in the hardware spec, and can it be fixed?
Serializing something that might take some time just seems troublesome.

> In other uses, concurrent access is fine and host does that today when it disables autoprobe on the PCI Bus and probes them in parallel after enabling sriov.
> I hope you understand that there are both use-cases exists which scan parallel and some serial.

Can at least some processing be made asynchronous? Like, you discover
the device, but then do the virtio setup out of band.