> From: Michael S. Tsirkin <>
> Sent: Friday, October 8, 2021 4:14 PM
>
> On Thu, Oct 07, 2021 at 03:42:24AM +0000, Parav Pandit wrote:
> > > There's no reason for a driver to choose any value - it has nothing else to
> do.
> > >
> > At least for the devices that we are seeing, driver choosing a default value of
> 2 to 3 minutes is good enough and of course useful.
>
> Well I don't get this of course yet. I guess it's useful for some workloads, but
> VM being blocked for 2 minutes breaks lots of workloads.
> Guests with 30 devices do exist, we are talking about an hour to start these
> guest.
>
In usual flow device doesn't take so long to reset. But every single time things doesn't go well in a system.
So device reset timeout is the upper bound limit. A user can always cancel/reboot a physical server or ctrl+c a qemu/kata process.
This can be done regardless of reset timeout anyway.
However the addition here indicates programable way for the sw to recover from such device or wait enough.
> I wonder whether we should instead just provide some guidance on how long is
> it ok for reset to take? Say if we want to address kata, <100ms boot time, I
> guess we can recomment not more than 10ms? Anything more would trigger at
> least a warning.
It may be even a pre-boot environment where 100msec or 10msec may be too short interval as other extreme of VM boot time example.
