On Wed, Jun 28, 2023 at 04:23:09AM +0000, Parav Pandit wrote: > > > From: Jason Wang <jasow...@redhat.com> > > Sent: Tuesday, June 27, 2023 11:46 PM > > > > Having it in the config space, then a type agnostic provisioning through > > config > > space + feature bits just works fine. > > > Provisioning is far simpler thing to do in device specific way than asking > device to store this value in onchip area which is rarely accessed.
I thought a lot about this over the weekend. I just do not see this working out, sorry. Two things is never easier than one. We already need config space with provisioning. In fact e.g. on Linux we want drivers to keep doing virtio_cread() and all the DMA tricks should be hidden behind the scenes. You don't like it that config space is on-chip? Build an interface for it not to be on chip. There is simply no downside to that. I came back after a small break and I still see this discussion that keeps playing out as a big distraction. In particular where are you doing to store the things that are for DMA? In system RAM? We don't *have* anywhere in system RAM to store this, we will need an interface to allocate system RAM and pass it to device for this idea to work. So in 1.3 where we won't have this, there is much less of an excuse to use a vq. > There are many fields of many features for 1.4 are discussed including this > one. All of these capabilities just cannot be stored in config space. config space is synchronous interface, vq is asynchronous. Setup is just too messy to do asynchronously. So yes, config space. Please let people just focus on fixing config space instead of temporary cvq hacks. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org