OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [PATCH v2] Add device reset timeout field


> From: Michael S. Tsirkin <mst@redhat.com>
> 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]