Re: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ

[Jason Wang <jasowang@redhat.com>]

å 2023/5/11 20:54, Michael S. Tsirkin åé:
> On Thu, May 11, 2023 at 03:04:40PM +0800, Jason Wang wrote:
> > On Wed, May 10, 2023 at 3:43âPM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > On Wed, May 10, 2023 at 03:01:25PM +0800, Jason Wang wrote:
> > > > On Wed, May 10, 2023 at 2:05âPM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > On Mon, May 08, 2023 at 10:23:39AM +0800, Jason Wang wrote:
> > > > > > > I thought so too originally. Unfortunately I now think that no, legacy is not
> > > > > > > going to be a byproduct of transport virtqueue for modern -
> > > > > > > it is different enough that it needs dedicated commands.
> > > > > > If you mean the transport virtqueue, I think some dedicated commands
> > > > > > for legacy are needed. Then it would be a transport that supports
> > > > > > transitional devices. It would be much better than having commands for
> > > > > > a partial transport like this patch did.
> > > > > OK I am beginning to get what you are saying.  So your criticism is
> > > > > this: what if device supports vq transport for modern, and we want to
> > > > > build a transitional device on top.  how will that look. yes?
> > > > Yes. I think it needs to be done through the transport virtqueue
> > > > otherwise the transport is not self-contained.
> > > I mean, any feature can be done over transport vq.
> > >
> > > But there is value in adding legacy commands to an otherwise
> > > modern device without reworking it completely to
> > > switch to a different transport.
> > There's probably no need for a rework since legacy is not complicated.
> > More below.
> >
> > > > > A reasonable thing to include at least in the commit log. Parav?
> > > > >
> > > > > You are also asking what if the device uses transport vq,
> > > > > and we want transitional on top of that.
> > > > > It's a fair question but I don't exactly get why would
> > > > > this legacy support feature be wanted for the vq transport
> > > > > and not for other transports.
> > > > Not sure I get the question, but all the existing transport support
> > > > legacy, if we want to have another, should the legacy support be a
> > > > must or not?
> > > This specific proposal is for tunneling legacy over admin vq.
> > > It can live alongside a normal modern VF, with hypervisor
> > > combining these to create a transitional device.
> > Exactly, but what I meant here is
> >
> > If we decide to use the admin vq, is there any good reason to tie it
> > to PCI if we don't want to tunneling PCI over adminq?
> >
> > Why not simply invent individual commands to access legacy facilities
> > like commands to access like what transport virtqueue did for modern
> > device?:
> >
> > 1) device features
> > 2) driver features
> > 3) queue address
> > 4) queue size
> > 5) queue select
> > 6) queue notify
> > 7) device status
> > 8) ISR status
> > 9) config msix
> > 10) queue msix
> > 11) device configuration space
> >
> > It focuses on the facilities instead of transport specific details
> > like registers (we don't even need legacy registers in this case), I
> > gives more deterministic behavior so we don't need to care about the
> > cross registers read/write.
> This needs thought, it is definitely more work.  Effort that could be
> maybe spent on new features.  What is the motivation
> here? supporting legacy mmio guests?


Probably. It tries to make legacy transport independent, and it's the 
way that how transport virtqueue want to be.

Thanks