virtio — archive

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

On Wed, Aug 02, 2023 at 11:51:21AM +0000, Parav Pandit wrote: > > > > From: Michael S. Tsirkin <mst@redhat.com> > > Sent: Wednesday, August 2, 2023 5:05 PM > > > > I said the opposite above, get and set is INBAND from guest driver to device > > for PF, VF and SIOV through its own delegated resource. > > > There is no AQ mediation from host. > > > Hence, there is no risk. > > > > I think there are different requirements from different people. > Yes. > There are two requirements. > 1. Build SIOV device that can live in hypervisor for having 1.x based PCI device in guest > > 2. Build SIOV device ground up that does not need to have existing limitations of 1.x. > > The transport VQ proposal 4 patches had heavy inclination for #1 without mentioning the real objective in the cover letter. > I was proposing that when virtio builds SIOV device it should start with #2. > Because #1 is sort of handled with sr-iov or vdpa already. > > #2 is more critical to get it right, after SIOV R2 spec is defined. Can't we address both? E.g. use a different group type. > > > For example, > > consider compatibility. I know it looks like super important right now, and we > > should make it possible, but it's just like with legacy interface - looked very far > > away when we introduced non-transitional, to the point where an option in > > linux to disable legacy talks about "flying cars", but the flying cars are nowhere > > to be seen and, while we are not where everyone can just drop pre-1.0 bits, a > > bunch of people are using e.g. vdpa without any legacy, express devices in > > qemu also disabled legacy, and so on. > > > > > > -- > > MST >