OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]