virtio — archive

[Michael S. Tsirkin <mst@redhat.com>]

On Wed, Aug 02, 2023 at 11:29:53AM +0000, Parav Pandit wrote: > > > > From: Michael S. Tsirkin <mst@redhat.com> > > 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