OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: proposal: use admin command (and aq) of the device to query config space



> 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.


> 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]