From: Parav Pandit <parav@nvidia.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"david.edmondson@oracle.com" <david.edmondson@oracle.com>,
"sburla@marvell.com" <sburla@marvell.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
Yishai Hadas <yishaih@nvidia.com>,
Maor Gottlieb <maorg@nvidia.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
Shahaf Shuler <shahafs@nvidia.com>
Subject: [virtio-dev] RE: [virtio-comment] RE: [PATCH v2 1/2] transport-pci: Introduce legacy registers access commands
Date: Wed, 24 May 2023 21:02:21 +0000 [thread overview]
Message-ID: <PH0PR12MB5481F68612984DE40B89BC14DC419@PH0PR12MB5481.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20230524155902-mutt-send-email-mst@kernel.org>
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Wednesday, May 24, 2023 4:13 PM
[..]
> > Sounds good to me.
> > What about discovery the notification place for the VF?
> > We have two options.
> > 1. discover them via AQ like config registers access 2. discover it
> > via extended PCI capability
> >
> > #1 is far more programable and does not need to bake in the PCI device
> layout.
>
> I think 2 is easier for drivers to use.
Yes.
Its trade off.
But not a huge difference from sw point of view as they use underlying apis.
As opposed to do that baking pci capabilities is slightly hard as it needs to intermix control path over registers..
Typically, CVQ and AQ etc a PCI device would do using some sort of firmware, so adding commands are easier than low level PCI capabilities based tunneling.
>
> > So this way one day in future we can get rid of it more easily for those PCI
> devices who may prefer everything in the hw.
>
> I think these devices are better off with a new transport using drastically less
> registers.
>
That way AQ scores more.
> > > a feels ok to me... maybe test the waters with express capability as
> > > well, it will come handy down the road I think.
> > Yes, if this is really needed for some OS, this addition will be possible in future
> in the spec and also of the devices in CC list here.
>
> hmm not sure what do you mean. I meant to put the capabilities with the new
> legacy bar in express config space.
>
I mean to say we should do AQ.
And if an OS can never implement two driver communication for legacy, may be at that future point a spec should evolve to provide this capability-based access.
> > The new capability in mind is:
> > VIRTIO_PCI_EXT_CAP_PCI_LEGACY_REG
> >
> > struct virtio_pci_legacy_cfg_cap {
> > struct virtio_pci_cap cap;
> > le32 addr; /* register offset, width, op=RD/WR,
> status:0=pending,1=done)
> > le32 reg_data;
> > };
>
> I would use cap64, cap is there because we did not think about 64 bit early
> enough.
>
Yes.
> > This will be hard to do for SIOV in future, so I prefer AQ cmd for config
> register access and notification discovery.
> > WDYT?
>
> I need to go back and look at how does SIOV tvq proposal manage notifications
> then. Do not remember off the top of my head.
SIOV tvq proposal does not tunnel the driver notifications.
It exposes the address and size of db region like how I had in similar command.
This is why it is not a transport vq and I suggest to rename to aq :)
Snippet of it below.
+The virtqueue notification area information can be get through the following commands:
+
+\begin{lstlisting}
+#define VIRTIO_TRANSPTQ_CTRL_VQ_NOTIFY 11
+ #define VIRTIO_TRANSPTQ_CTRL_VQ_NOTIFY_GET 0
+
+struct virtio_transportq_ctrl_vq_notification_area {
+ u64 address;
+ u64 size;
+};
+\end{lstlisting}
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2023-05-24 21:02 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-06 0:01 [virtio-dev] [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ Parav Pandit
2023-05-06 0:01 ` [virtio-dev] [PATCH v2 1/2] transport-pci: Introduce legacy registers access commands Parav Pandit
2023-05-17 5:44 ` [virtio-dev] " Michael S. Tsirkin
2023-05-17 19:32 ` [virtio-dev] " Parav Pandit
2023-05-18 19:42 ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-05-18 20:51 ` [virtio-dev] " Parav Pandit
2023-05-19 1:54 ` [virtio-dev] " Jason Wang
2023-05-19 2:04 ` [virtio-dev] " Parav Pandit
2023-05-19 6:06 ` [virtio-dev] " Michael S. Tsirkin
2023-05-19 16:37 ` [virtio-dev] " Parav Pandit
2023-05-21 9:16 ` [virtio-dev] " Michael S. Tsirkin
2023-05-21 13:21 ` [virtio-dev] " Parav Pandit
2023-05-21 14:33 ` [virtio-dev] " Michael S. Tsirkin
2023-05-21 14:44 ` [virtio-dev] " Parav Pandit
2023-05-22 20:07 ` [virtio-dev] " Michael S. Tsirkin
2023-05-22 21:05 ` [virtio-dev] " Parav Pandit
2023-05-22 21:34 ` [virtio-dev] " Michael S. Tsirkin
2023-05-23 17:13 ` [virtio-dev] " Parav Pandit
2023-05-23 18:48 ` [virtio-dev] " Michael S. Tsirkin
2023-05-23 22:22 ` [virtio-dev] " Parav Pandit
2023-05-24 1:17 ` [virtio-dev] " Jason Wang
2023-05-24 10:07 ` Michael S. Tsirkin
2023-05-24 19:18 ` [virtio-dev] " Parav Pandit
2023-05-24 20:12 ` [virtio-dev] " Michael S. Tsirkin
2023-05-24 21:02 ` Parav Pandit [this message]
2023-05-22 21:42 ` Michael S. Tsirkin
2023-05-22 0:54 ` Jason Wang
2023-05-22 2:46 ` [virtio-dev] " Parav Pandit
2023-05-22 19:35 ` [virtio-dev] " Michael S. Tsirkin
2023-05-06 0:01 ` [virtio-dev] [PATCH v2 2/2] transport-pci: Add legacy register access conformance section Parav Pandit
2023-05-06 2:31 ` [virtio-dev] Re: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ Jason Wang
2023-05-07 13:44 ` Michael S. Tsirkin
2023-05-08 2:23 ` Jason Wang
2023-05-08 17:07 ` Parav Pandit
2023-05-09 3:44 ` Jason Wang
2023-05-09 3:56 ` [virtio-dev] " Parav Pandit
2023-05-10 3:51 ` [virtio-dev] " Jason Wang
2023-05-10 4:22 ` Jason Wang
2023-05-10 16:07 ` Parav Pandit
2023-05-11 7:20 ` [virtio-dev] Re: [virtio-comment] " Jason Wang
2023-05-11 11:35 ` Michael S. Tsirkin
2023-05-15 5:08 ` Jason Wang
2023-05-15 15:25 ` [virtio-dev] " Parav Pandit
2023-05-10 16:04 ` [virtio-dev] " Parav Pandit
2023-05-11 7:17 ` Jason Wang
2023-05-11 14:31 ` [virtio-dev] " Parav Pandit
2023-05-15 5:12 ` [virtio-dev] Re: [virtio-comment] " Jason Wang
2023-05-15 15:26 ` [virtio-dev] " Parav Pandit
2023-05-10 6:04 ` [virtio-dev] " Michael S. Tsirkin
2023-05-10 7:01 ` Jason Wang
2023-05-10 7:43 ` Michael S. Tsirkin
2023-05-10 16:13 ` Parav Pandit
2023-05-11 7:04 ` Jason Wang
2023-05-11 12:54 ` Michael S. Tsirkin
2023-05-11 13:02 ` [virtio-dev] " Parav Pandit
2023-05-15 7:30 ` [virtio-dev] " Jason Wang
2023-05-15 10:08 ` Michael S. Tsirkin
2023-05-15 14:30 ` [virtio-dev] " Parav Pandit
2023-05-23 18:16 ` [virtio-dev] " Michael S. Tsirkin
2023-05-23 21:32 ` [virtio-dev] " Parav Pandit
2023-05-24 5:56 ` [virtio-dev] " Michael S. Tsirkin
2023-05-24 18:57 ` [virtio-dev] " Parav Pandit
2023-05-24 19:58 ` [virtio-dev] " Michael S. Tsirkin
2023-05-24 20:01 ` [virtio-dev] " Parav Pandit
2023-05-24 20:15 ` [virtio-dev] " Michael S. Tsirkin
2023-05-15 15:59 ` [virtio-dev] " Parav Pandit
2023-05-16 6:21 ` [virtio-dev] " Michael S. Tsirkin
2023-05-16 19:11 ` [virtio-dev] " Parav Pandit
2023-05-16 20:58 ` [virtio-dev] " Michael S. Tsirkin
2023-05-16 21:19 ` [virtio-dev] " Parav Pandit
2023-05-16 21:23 ` [virtio-dev] " Michael S. Tsirkin
2023-05-16 21:30 ` [virtio-dev] " Parav Pandit
2023-05-15 7:13 ` [virtio-dev] " Jason Wang
2023-05-11 13:15 ` [virtio-dev] " Parav Pandit
2023-05-11 13:45 ` [virtio-dev] " Michael S. Tsirkin
2023-05-12 14:03 ` Parav Pandit
2023-05-16 3:54 ` Jason Wang
2023-05-16 19:35 ` [virtio-dev] RE: [virtio-comment] " Parav Pandit
2023-05-16 21:11 ` [virtio-dev] " Michael S. Tsirkin
2023-05-16 21:49 ` [virtio-dev] " Parav Pandit
2023-05-16 21:56 ` [virtio-dev] " Michael S. Tsirkin
2023-05-10 16:11 ` [virtio-dev] " Parav Pandit
2023-05-10 16:16 ` Michael S. Tsirkin
2023-05-10 17:33 ` [virtio-dev] " Parav Pandit
2023-05-10 21:08 ` Parav Pandit
2023-05-10 21:33 ` [virtio-dev] " Michael S. Tsirkin
2023-05-10 21:48 ` [virtio-dev] " Parav Pandit
2023-05-11 7:06 ` [virtio-dev] " Jason Wang
2023-05-11 13:04 ` Michael S. Tsirkin
2023-05-15 5:19 ` Jason Wang
2023-05-15 15:31 ` [virtio-dev] " Parav Pandit
2023-05-11 13:28 ` Parav Pandit
2023-05-11 13:38 ` [virtio-dev] " Michael S. Tsirkin
2023-05-11 16:00 ` [virtio-dev] " Parav Pandit
2023-05-11 20:47 ` Parav Pandit
2023-05-11 20:58 ` [virtio-dev] " Michael S. Tsirkin
2023-05-11 21:03 ` [virtio-dev] " Parav Pandit
2023-05-15 16:55 ` Parav Pandit
2023-05-15 7:10 ` [virtio-dev] " Jason Wang
2023-05-15 15:49 ` [virtio-dev] " Parav Pandit
2023-05-15 17:44 ` [virtio-dev] " Michael S. Tsirkin
2023-05-15 17:51 ` [virtio-dev] " Parav Pandit
2023-05-15 17:56 ` [virtio-dev] " Michael S. Tsirkin
2023-05-15 18:00 ` [virtio-dev] " Parav Pandit
2023-05-15 18:01 ` [virtio-dev] " Michael S. Tsirkin
2023-05-15 18:05 ` [virtio-dev] " Parav Pandit
2023-05-16 3:37 ` [virtio-dev] " Jason Wang
2023-05-16 3:43 ` Jason Wang
2023-05-16 5:38 ` Michael S. Tsirkin
2023-05-16 3:28 ` Jason Wang
2023-05-16 3:45 ` [virtio-dev] " Parav Pandit
2023-05-16 4:08 ` [virtio-dev] " Jason Wang
2023-05-16 19:29 ` [virtio-dev] " Parav Pandit
2023-05-16 21:09 ` [virtio-dev] " Michael S. Tsirkin
2023-05-16 21:41 ` [virtio-dev] " Parav Pandit
2023-05-16 21:54 ` [virtio-dev] " Michael S. Tsirkin
2023-05-16 4:18 ` Michael S. Tsirkin
2023-05-07 9:04 ` Michael S. Tsirkin
2023-05-08 16:54 ` Parav Pandit
2023-05-15 20:29 ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-05-15 20:56 ` [virtio-dev] " Parav Pandit
2023-05-16 4:32 ` [virtio-dev] " Michael S. Tsirkin
2023-05-16 18:45 ` [virtio-dev] " Parav Pandit
2023-05-16 20:42 ` [virtio-dev] " Michael S. Tsirkin
2023-05-23 6:38 ` [virtio-dev] " Michael S. Tsirkin
2023-05-23 17:28 ` [virtio-dev] " Parav Pandit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=PH0PR12MB5481F68612984DE40B89BC14DC419@PH0PR12MB5481.namprd12.prod.outlook.com \
--to=parav@nvidia.com \
--cc=cohuck@redhat.com \
--cc=david.edmondson@oracle.com \
--cc=jasowang@redhat.com \
--cc=maorg@nvidia.com \
--cc=mst@redhat.com \
--cc=sburla@marvell.com \
--cc=shahafs@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).