Re: [PATCH V7 v7] virtio: introduce SUSPEND bit in device status

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Sep 04, 2024 at 11:07:25AM +0800, Jason Wang wrote:
> On Tue, Sep 3, 2024 at 6:37 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Tue, Sep 03, 2024 at 06:35:59AM -0400, Michael S. Tsirkin wrote:
> > > > >
> > > > > But I don't like it that looking at the registers, one does not know the device
> > > > > state. Hidden state is bad for debuggability.
> > > > > We have 4 states:
> > > > > suspending->suspended->resuming->resumed
> > > > > so we need a register with at least 2 bits.
> > > > >
> > > > > we could steal 2 bits from status but it seems a bit much.
> > > > >
> > > > This is why letting the status tell the status and control register to control thing is elegant.
> > >
> > >
> > > No argument here.
> >
> > Or, to be more precise, our status is driver status.
> 
> It looks like the device actually otherwise there's no need for
> re-read or poll for things like reset and others.

The need is there for complex device state transitions, which
can not reasonably block a read response.
Another standard approach with PCI is to specify the time
transitions can take. I consider that less elegant -
is this what you are advocating? The advantage is that
driver does not load the pci bus with constant re-polling.
The disadvantage is that it is hard to pick a universal
number.  A combination of these approaches might work,
e.g. a recommended timeout then poll.

> Anyhow driver know
> its own status.
> 
> Thanks

indeed, the status register is there to inform the device about
the driver status.



> > If we need
> > to reflect and control device status, we need something else.
> >