On Sun, Jun 04, 2023 at 02:48:59PM +0000, Parav Pandit wrote: > > > > From: Michael S. Tsirkin <[email protected]> > > Sent: Sunday, June 4, 2023 10:23 AM > > > > > > > E.g. the notification can include VF# + VQ#? > > > > > > At least as an option? > > > > > No. we discussed this before to have each device on its own BAR. > > > > > Hence no > > > > VF# in the doorbell. > > > > doorbell == available notification? yes in fact it's not strictly needed > > since PF can > > use a different address for each VF. > > > Sorry for doorbell terminology. > Yes, available buffer notification. > > > > > I am talking about the idea of exposing legacy VQ notifications in the PF > > BAR. To > > me it looks nicely symmetrical, all legacy emulation goes through PF, and I > > think > > it simplifies a bunch of driver code moving some complexity into hardware > > which is what you seem to be intent on? > > > Symmetrical only looks fine in emails. > In real device, it doesn't. We also discussed this before. > I will capture this in alternatives section of v4. > > Each VF has its own available buffer notification in hardware like 1.x. > We do not want to duplicate (and add) such functionality on the PF BAR > hardware when it already exists on the VF.
yes but here we are talking about legacy notifications, not 1.x > > > > Will it help if I get some feedback from windows driver team on the > > > > design? > > > > > > > May be. I am not sure, given that these drivers are not inbox, they are > > > not in > > purview of the OS vendor. > > > > Exactly a reason we might not see new APIs? > > > I don't know. Exactly. > > > And OS vendor improves the OS APIs in the future for new use cases. > > > > > > Even the SR-IOV model in Windows is not elaborate as Linux AFAIK. > > > So I am not sure how much value add we will have. > > > But sure, better to have their view. > > > Will you please add them to the discussion here or I should check? > > > > I don't think they are subscribed to the list, so I can't. > > Will talk to them. > > > Ok. > > > > Did anyone use vdpa acceleration on Windows? > > > Do you have data points that someone wants VF acceleration on Windows > > hypervisor? > > > If you bring the use case, I would like to see there commitment to > > > develop the > > code also and it will be great to have virtio there. > > > > We are talking about an interface that will be used tens of years from now. > > If the > > interface is awkward to use on some platforms let's make it easier not hide > > behind excuses of no demand to fix it as of last Friday. > It is not hiding. > The fact that virtio drivers are not inbox. I don't see an actual user by the > OS vendor for the decade passed. But why does it matter? There are a bunch of users of virtio, I know that. > And, I do not anticipate use of legacy for tens of years from now. > > It is not even a conclusion that it is awkward to use. > You are concluding that one OS may never want to evolve their kernel APIs. They might. That takes many years too. > I don't see it that way. > We have seen with two hypervisors evolving their kernel APIs and both have > large deployments. > > I am not pessimistic that 3rd OS vendor will not evolve. > > > Device vendors can choose not to support some platforms, that is their > > decision. As a compromise, consider device exposing this both in a PF and > > in a > > VF and let's allow driver to use what's most convenient? > > > I also said yes, for this and you said "lets do one way". > > So, when a 2nd OS vendor cannot use IPR scheme that they have, and they MUST > have everything through ONLY VF, to support them, a HW vendor will build PCI > device with VF legacy access registers stay in the VF. > And spec update will be done. > > We really don't see this happening. So better to build a practical spec. > > And if this was important, I am still puzzled why you say "Just AQ is fine" > in v2 and why you wait for next 2 weeks for v3 to show up to raise the > concern now contradicting your ACK. Because this is just AQ. All I am asking is that the BAR refers to PF, same AQ command. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
