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: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ



> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Sunday, June 4, 2023 9:34 AM
> 
> On Fri, Jun 02, 2023 at 11:36:01PM +0300, Parav Pandit wrote:
> > This short series introduces legacy registers access commands for the
> > owner group member PCI PF to access the legacy registers of the member VFs.
> 
> Note that some work will be needed here to fix up grammar and spelling
> mistakes.
>
I already verified using codespell but I guess it missed few.
If you have specific already identified, let me know.
If not I will run a different checker.
 
> > If in future any SIOV devices to support legacy registers, they can be
> > easily supported using same commands by using the group member
> > identifiers of the future SIOV devices.
> 
> Yes, with the exception of
> VIRTIO_ADMIN_CMD_LQ_NOTIFY_QUERY - currently refers to VF BAR,
> subfunctions do not have it.
A subfunction will also have its own BAR carved out from the PF BAR.
A subfunction definition will be as contains as possible.

> Can we find a way to have it in the PF BAR instead?
At subfution level also it will be a BAR number, which will map to the PF BAR.

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

> If not can you add some info explaining why not?
Yes, Good point.
I will add the commit log explanation that every VF has its own BAR hence it does not use PF BAR.


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