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

[Jason Wang <jasowang@redhat.com>]

å 2023/5/11 21:04, Michael S. Tsirkin åé:
> 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"?


Yes.


> 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.


Right, but as discussed, a possible user is the SIOV transitional device 
via transport virtqueues.


> 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?


My understanding is, for any case, we need such clarifications. What 
Parav proposed here is not the access to the actual registers but stick 
to the semantic of those registers. I think we must say high 32bits of 
the features must be assumed to be 0.


> Want to share how is transport vq closer than
> legacy pci to what we might want?


I'm not sure I get the question, but in another thread I show 10+ 
commands to access the legacy facilities which is really very close to 
the transport virtqueue.

Thanks


> > > 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