On Wed, Aug 02, 2023 at 11:29:53AM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <>
> > Sent: Wednesday, August 2, 2023 4:56 PM
> >
> > On Wed, Aug 02, 2023 at 09:57:47AM +0000, Parav Pandit wrote:
> > > > If you care about admin
> > > > virtqueue then device configuration space is not the only thing that
> > > > can be "ever growing", common_cfg is another one.
> > > The idea is to do minimal bootstrap work from the common config space and
> > switch to the queue.
> > > So common config shouldnât be growing either other than minimal bootstrap
> > functionality.
> > > Hence, common config also to be available via dma command.
> >
> > That is more like a new transport. I thought this proposal is focusing on device
> > specific config - let's get a handle on that first?
> > "common config" is a pci transport specific thing.
>
> Sure, device config is the real pain point we are trying to solve first.
>
> Using cvq for those devices who has it seems the most optimal approach.
> If we liberate ourselves from single monolithic config space structure and move to query device capabilities, resources, configuration, at functionality level, life is lot easier.
> What are your thoughts?
Splitting transport and device config is exactly what I'm talking about.
I agree transport should probably be split further -
it only made sense for legacy so we don't need to spend
specification effort on legacy.
splitting device config would require changes to all devices -
I don't see how it's worth the effort.
--
MST
