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

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

On Thu, May 11, 2023 at 03:06:48PM +0800, Jason Wang wrote:
> > With that I don't see legacy 3 commands anyway conflict with [1].
> 
> It doesn't, but it's not elegant since:
> 
> 1) Modern transport, admin virtqueue with well defined transport commands
> 2) Legacy transport, works moe like a PCI transport on top of the
> admin virtqueue
> 
> Transport virtqueue tend to be transport independent, but 2) tie it
> somehow to the PCI.

This "somehow" matters though. The connection is really just the
common config layout.

> That's why I suggest to
> 
> 1) introduce legacy transport commands
> 
> or
> 
> 2) tweak your proposal to become a PCI over admin virtqueue

So you are saying it's really not generally "legacy over
admin queue" it is more like "legacy pci over admin queue"?
Good point.

And I feel it's a good point that this chooses legacy pci but it could
really be mmio or ccw or the upcoming vq transport just as well.  I suspect
mmio or ccw won't work well for a physical pci card though.
transport vq might, but I am worried we'll have to spend extra
work clarifying it's a legacy interface. For example we will
have to explain that only 32 bits of features must be used.
Focusing more effort on transport vq is attractive though ...
It is worth examining this option in more depth.
Did you? Want to share how is transport vq closer than
legacy pci to what we might want?


> > Some commands functionality is common between [1] and this proposal.
> > But that's how the legacy is. It is confined to legacy emulation.
> > So [1] can be done as follow_on to AQ and these series.
> >
> > A small note about [2].
> > virtio_transportq_ctrl_dev_attribute should be detached from CREATE call and split to two commands.
> > So that VF and SF/SIOV can both utilize it.
> > SF/SIOV_R1 can use the creation and config part.
> > VFs will use only the device features + config space.
> 
> Good point. This could be fixed.
> 
> Thanks
> 
> >


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org