Re: [PATCH v4 16/22] usb/msd: Split async packet tracking into data and csw

[Kevin Wolf <kwolf@redhat.com>]

Am 05.05.2025 um 15:05 hat Kevin Wolf geschrieben:
> Am 02.05.2025 um 05:30 hat Nicholas Piggin geschrieben:
> > The async packet handling logic has places that infer whether the
> > async packet is data or CSW, based on context. This is not wrong,
> > it just makes the logic easier to follow if they are categorised
> > when they are accepted.
> > 
> > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > ---
> >  include/hw/usb/msd.h |   5 +-
> >  hw/usb/dev-storage.c | 121 +++++++++++++++++++++++++++----------------
> >  2 files changed, 79 insertions(+), 47 deletions(-)
> > 
> > diff --git a/include/hw/usb/msd.h b/include/hw/usb/msd.h
> > index f9fd862b529..a40d15f5def 100644
> > --- a/include/hw/usb/msd.h
> > +++ b/include/hw/usb/msd.h
> > @@ -33,8 +33,11 @@ struct MSDState {
> >      struct usb_msd_csw csw;
> >      SCSIRequest *req;
> >      SCSIBus bus;
> > +
> >      /* For async completion.  */
> > -    USBPacket *packet;
> > +    USBPacket *data_packet;
> > +    USBPacket *csw_in_packet;
> 
> This makes the state more complex, because there is a rule here that
> isn't explicit in the code: At most one of data_packet or csw_in_packet
> can be set at the same time.
> 
> Both are quite similar, so most of the patch just duplicates things that
> are currently done for s->packet.
> 
> Wouldn't it make more sense to have one USBPacket pointer, but some
> state that explicitly tells us what we're waiting for, data or the
> status? I was thinking of a new bool at first, but on second thoughts,
> s->mode looks quite similar to what we need here.
> 
> What if we just introduce a new state in the s->mode state machine for
> "CSW read in progress" as opposed to USB_MSDM_CSW meaning "expecting the
> host to read the CSW next"? Then the cases for which you currently set
> s->csw_in_packet would instead transition to this new state, and
> usb_msd_command_complete() (which has the only real change in this
> patch) could just directly rely on s->mode.

After looking at the rest of the series, this is probably not what we
want either.

I think a big part of the problem why this device is hard to understand
is that it's too much centered around what the host does rather than
what the core logic of the device is. Which is really simple:

    while (!unrealizing) {
        cbw = read_in_packet();
        req = start_scsi_req();
        ret = wait_for_scsi_req(req);
        write_out_packet(status_to_csw(ret));
    }

This flow (which is really Figure 1 in Chapter 5 in the spec) is nowhere
to be seen in the code. Can we change things to look more like this?
Could be almost literally this if we make it coroutine based, or just
the callback based equivalent of it.

And then when we receive a packet, we just queue it as the next in or
out packet, and leave it to the main state machine/coroutine to make use
of the packet or wait for one if it's missing.

Kevin