> From: Michael S. Tsirkin <m...@redhat.com> > Sent: Monday, April 3, 2023 4:03 PM > > On Mon, Apr 03, 2023 at 07:48:56PM +0000, Parav Pandit wrote: > > > OK but supporting them with a passthrough driver such as vfio does > > > not seem that important. > > Not sure on what basis you assert it. > > I clarified in the cover letter that these are the user level requirements > > to > support transitional and non-transitional devices both via single vfio > subsystem. > > And what is so wrong with vdpa? Really I don't see how the virtio spec needs > to > accomodate specific partitioning between linux modules, be it vdpa or vfio. > Way beyond the scope of the driver. > vdpa has its own value.
Here requirements are different as listed so let's focus on it. > But anyway, my main > point is about DMA. On the one hand you are asking for a VQ based > management interface because it saves money. On the other you are saying > DMA operations take extremely long to the point where they are unusable in > the boot sequence. I think you missed the point I described few emails back. The legacy registers are subset of the 1.x registers, so a device that implements existing 1.x registers, they get legacy registers for free. Hence, there is no _real_ saving. > So what is it? Was admin vq a mistake and we should do memory mapped? No. Certainly not. AQ is needed for LM, SR-IOV (SR-PCIM management), SIOV device life cycle. > Or is > legacy emulation doable over a vq and latency is not a concern, and the real > reason is because it makes you push out a host driver with a bit less effort? > Legacy registers emulation is doable over VQ and has its merits (I listed in previous email). I forgot to mention in previous email that device reset is also better via tvq. It is just that legacy_registers_transport_vq (LRT_VQ) requires more complex hypervisor driver and only works for the VFs. At spec level, MMR has value on the PF as well, hence I previously proposed last week on your first email that spec should allow both. Efforts of hypervisor not really a big concern. Once we converge that LRT_VQ is good, it is viable option too. I will shortly send out little more verbose command on lrt_vq so that its optimal enough. > I just do not see how these claims do not contradict each other. An AQ for queuing, parallelism, memory saving. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
