Re: [virtio-comment] RE: [PATCH V2 3/6] virtio: dont reset vqs when SUSPEND

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

On Fri, Nov 24, 2023 at 07:50:42PM +0800, Jason Wang wrote:
> > I frankly don't see how a bit which is completely non-orthogonal with
> > device and driver state can be useful for debug.
> 
> The bit is to make sure the state of a device doesn't change. It may
> help or not just like if you want to pause a cpu/process during the
> debug.

Heh. But it would be much better to have an orthogonal state
that driver can just set without worrying much about
device being broken somehow.


> > For debug you want something that just always works.
> > Not an interface that has so many requirements it will break if
> > you look at it sidewise.
> >
> >
> > > > >
> > > > I donât see wasting time here.
> > > > If its debug, its debug.
> > > > If its migration, it is migration.
> > > > If its pm, its pm.
> > >
> > > Obviously not. Migration should leverage existing facilities as much
> > > as possible instead of duplicating them.
> >
> > I don't think there's anything obvious here.  A lot of device state
> > can't be easily accessed with existing facilities.
> 
> Then we can invent new things.

So the approach this patchset takes is a single interface for
all state introspection. Some duplication of functionality
for the sake of consistency. You don't like it fine but
there is nothing obvious that it's a bad thing. It's a tradeoff.

> > The logical
> > continuation of your reasoning would be to add state introspection
> > commands e.g. to cvq in virtio net and then use tricks like shadow vq to
> > issue these.
> 
> For the device state, yes. Because it is device logic and it is not
> what platform or transport can know.

Exactly as I thought. Don't think shadow VQ is something we
can reasonably make a single migration mechanism though.
It feels fragile and heavyweight. It's more of a work
around hardware limitations.


> > Yea, possible, but can we not go there please?  Nothing is
> > wrong with just building commands that do exactly what we want them to
> > do instead of trying to build a ship in a bottle.
> 
> But it's not the case for others.
> 
> E.g in Parav's proposal, it tries to rule P2P behaviour via virtio
> admin commands when there is a duplication

Yes there's some duplication. Advantage is consistency.  I actually
suggested ways to reduce duplication, by using transport offsets as
tags.  Finding a right balance means we all need to stop going to
extremes, I wish you and lingshan would stop trying to force everyone
to use registers and parav would stop trying to force dma.

> and a layer violation.

layers are only good if they make sense.

> Thanks
> 
> 
> >
> > --
> > MST
> >