On Wed, Aug 02, 2023 at 11:51:21AM +0000, Parav Pandit wrote:
>
>
>
>
From: Michael S. Tsirkin <>
>
> 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
>
