[virtio-dev] Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

Michael S. Tsirkin
2023-04-18T11:58:20Z

On Tue, Apr 18, 2023 at 01:30:43AM +0000, Parav Pandit wrote:
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Monday, April 17, 2023 8:37 PM
>
> > > > > Do you mean say we have three AQs, AQ_1, AQ_2, and AQ_3;
> > > > > AQ_1 of the PF used by admin work as SIOV device create, SRIOV
> > > > > MSIX
> > > > configuration.
> > > > > AQ_2 of the PF used for transporting legacy config access of the
> > > > > PCI VF
> > > > > AQ_3 of the PF for some transport work.
> > > > >
> > > > > If yes, sounds find to me.
> > > >
> > > > Latest proposal simply leaves the split between AQs up to the driver.
> > > > Seems the most flexible.
> > > Yes. It is. Different opcode range and multiple AQs enable to do so.
> >
> > Right, so it would be some facility that makes the transport commands of
> > modern and legacy are mutually exclusive.
>
> Ok. I didn’t follow the mutual exclusion part.
> If a device has exposed legacy interface it will have to transport legacy access via its PF.
> Same device can be transitional, and its 1.x interface doesn’t need to through this transport channel of PF, right?

I think in any case, using device through two transports at the same
time shouldn't be legal.

--
MST