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: [virtio-dev] RE: [PATCH v2] Add device reset timeout field

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, October 28, 2021 11:21 AM
> On Thu, Oct 28, 2021 at 04:01:52AM +0000, Parav Pandit wrote:
> > >   how it looks like, whether there is a timeout is
> > >   a separate question.
> >
> > > E.g. a read counter sounds
> > >   more generic, if device is stuck it can just stop
> > >   incrementing it.
> > This is not scalable solution for hundreds of devices and it breaks the layering
> too.
> > A virtio layer itself is not in up_state to perform counter update.
> > A non virtio layer is expected to implement this counter. This is not right.
> Donnu what does the above mean. My point is simple: there's little difference
> between device being stuck during firmware boot and device being stuck right
> after boot.
Virtio functionality is something to be implemented by the virtio layer in the device.
When the device is booting, virtio layer may not have yet booted to update this counter. (device is not stuck).
Some other layer before the virtio layer within the device is asked to implement virtio counters.

And hence it incorrect to have such counter to indicate that the device is booting.

A init bit is good enough to indicate that initialization has not yet finished. When the virtio layer is booted in the device, it can connect to this layer to update about its init status.
This is far more scalable and don't break layers.

Secondly, a free flowing counter implementation for tens of hundreds of devices doesn't scale in pre-init stage.

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