[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]