[virtio-dev] RE: [virtio-comment] RE: [PATCH v2 1/2] transport-pci: Introduce legacy registers access commands

Parav Pandit
2023-05-21T13:21:25Z

> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Michael S. Tsirkin
> Sent: Sunday, May 21, 2023 5:17 AM

> > The Notification of the VFs are on the VF BAR for modern or legacy.
> > One needs to build additional cross forwarding hardware from PF to VF for the
> doorbells.
>
> I think doorbells are driver notifications (linux driver calls them kicks)?
> I don't understand what you are saying above really.
> what can and what can't be done?
>
VF has the notification BAR region.
All 1.x and legacy such notification lands on the VF BAR.

> Again all this idea (as opposed to Jason's transport vq) is to have a simple
> software model. Attaching a driver to two devices at the same time is hard to
> achive e.g. under windows.
>
Yet you initiate same discussion point that we already discussed again after summarizing.
A driver is not attached to two devices.
A driver is attached to a single device.
A device uses a parent/owner group device to access legacy.

Software model may evolve over time.

>
> > And it cannot utilize what already exists for 1.x VF.
> >
> > > 2. It should be possible to send notifications through an admin
> > command too,
> > > otherwise admin commands are an incomplete set of functionality.
> > >
> > Yes. it is only for the functionality. As we discussed in past already, this will not
> get any performance.
>
> Performance might be ok if hardware disables kicks most of the time.
>
Even for the first kick it is order of magnitude higher.
Kicks is the natural tool for the low latency.

>
> > > 3. I feel using a capability to describe legacy notification
> > > area would be better just because we already have a
> > > structure for this. make it an express capability if you like.
> > The AQ command interface is far more programable object than PCI capability
> to return this admin info.
> > Hence I prefer AQ cmd.
>
> I feel your preferences for 1 and 3 conflict. If you really insist on kicks being on
> VFs then at least let us make VF driver in the host simple.
It is straight forward.

If you prefer the "offset" example of past,

If (legacy_offset == queue_notify_offset)
*db = guest_supplied_q_notify_content;
else
virtio_net_send_aq_cmd();

"simple" is really a subjective term in this context.

> If it has to talk to PF
> driver things are really complex. At this point we are very very far from VFIO
> model, and then what exactly have we gained by implementing legacy control
> path in hardware?
It is in the VFIO model, legacy largely falls in the special path for backward compat for the hw devices.

> Let's do software with maybe a couple of features such as
> VIRTIO_NET_F_LEGACY_HEADER.
>
We have already these design choices and tradeoff in v0 and v1, it doesn't fit the requirements.
We cannot iterate exact 100% same points again in this summary discussion.

If you have any different comments from v0 and v1, please share, otherwise these commands should proceed.

What you hint is saying hey, "transport everything through the PF, then why do you have a VF?"
We again past that discussion.

This is different requirement, than
"There is a VF passthrough accessible directly from the guest without a VI, some of them need to have legacy support also".
Hence how do one make that legacy guest utilize it the VF in passthrough manner for 1.x and 0.9.5.
With this proposal 0.9.5 slow registers are accessed over the owner group admin PF keeping the whole model and functionality intact.

This is it.