From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.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: [PATCH v3 2/3] transport-pci: Introduce legacy registers access commands
Date: Sun, 4 Jun 2023 10:13:30 -0400 [thread overview]
Message-ID: <20230604095615-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB5481195B63FD61C35447FFDFDC4CA@PH0PR12MB5481.namprd12.prod.outlook.com>
On Sun, Jun 04, 2023 at 01:51:20PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Sunday, June 4, 2023 9:22 AM
>
> > > +The driver that may use the driver notifications region of the VF
> > > +device returned in this result likely attain higher performance or
> > > +the drier may use the VIRTIO_ADMIN_CMD_LREG_WRITE command.
> >
> > Obtain I guess ... but how? There's no explanation.
> >
> Do you suggest to rewrite, above as below?
>
> The driver that MAY use the driver notifications region of the VF likely obtain higher performance.
> The driver may use VIRTIO_ADMIN_CMD_LCC_REG_WRITE command for doorbell notifications.
No this does not address the issue that there is no description of how
this command is used just a hint at what it returns. So this gets us
some offset into some bar now what? I am guessing writing vqn at this
offset into bar has the same effect as issuing
VIRTIO_ADMIN_CMD_LCC_REG_WRITE with offset 16 and data including the
vqn?
BTW all these may/must/should need to go into conformance section.
Generally the way we structure the spec is an explanation of
the theory of operation (mostly missing here)
> > > +\begin{note}
> > > +The PCI VF device should not use PCI BAR 0 when it prefers to support
> > > +legacy interface registers access using its group owner PF. This
> > > +enables hypervisor software to operate with least complexities to
> > > +compose a legacy interface I/O space BAR and passthrough other PCI
> > > +BARs and PCI device capabilities to the guest virtual machine without any
> > translation.
> > > +\end{note}
> >
> > Is this related to this last command somehow? what does it mean for PCI VF
> > device to use a BAR? not use a BAR? Prefer what to what?
>
> This is no different than v2, not sure why to discuss this in v3.
v2 had other issues so I missed this one.
> But ok.
>
> No. It is not related to last command.
> What does a PCI Device use BAR for?
To reserve address space and know which addresses to claim.
Generally if I heard "not use BAR0" I would assume that the
meaning is that VF BAR0 in SRIOV expended capability
should be 0. However, that affects all VFs and not just
this VF so I don't really know what can it mean.
> As described in the spec, it uses the BAR in struct virtio_pci_cap for exposing various things.
Now I'm confused.
So do you mean the \field{bar} in virtio_pci_cap or PCI BAR?
> So it means that PCI VF should use other than PCI BAR 0 for various Virtio Structure PCI Capabilities that it exposes.
I suspect you then want to say "should not expose to driver
any structures inside it's BAR0"?
And does this include this new command you are adding or not?
It mentions bar too. What about e.g. MSIX tables? Could there be other
capabilities referring to a BAR? How does hypervisor know
whether VF followed this rule (it's a should, not a hard rule after all)?
--
MST
---------------------------------------------------------------------
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-06-04 14:13 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 20:36 [virtio-dev] [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ Parav Pandit
2023-06-02 20:36 ` [virtio-dev] [PATCH v3 1/3] admin: Split opcode table rows with a line Parav Pandit
2023-06-02 20:36 ` [virtio-dev] [PATCH v3 2/3] transport-pci: Introduce legacy registers access commands Parav Pandit
2023-06-04 13:22 ` [virtio-dev] " Michael S. Tsirkin
2023-06-04 13:51 ` [virtio-dev] " Parav Pandit
2023-06-04 14:13 ` Michael S. Tsirkin [this message]
2023-06-04 14:32 ` Parav Pandit
2023-06-04 14:41 ` [virtio-dev] " Michael S. Tsirkin
2023-06-04 15:01 ` [virtio-dev] " Parav Pandit
2023-06-04 22:10 ` [virtio-dev] " Michael S. Tsirkin
2023-06-04 23:57 ` [virtio-dev] " Parav Pandit
2023-06-08 18:34 ` [virtio-dev] " Michael S. Tsirkin
2023-06-08 18:55 ` [virtio-dev] " Parav Pandit
2023-06-08 19:00 ` [virtio-dev] " Michael S. Tsirkin
2023-06-08 19:04 ` [virtio-dev] " Parav Pandit
2023-06-02 20:36 ` [virtio-dev] [PATCH v3 3/3] transport-pci: Add legacy register access conformance section Parav Pandit
2023-06-04 13:34 ` [virtio-dev] Re: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ Michael S. Tsirkin
2023-06-04 13:41 ` [virtio-dev] " Parav Pandit
2023-06-04 13:55 ` [virtio-dev] " Michael S. Tsirkin
2023-06-04 14:10 ` [virtio-dev] " Parav Pandit
2023-06-04 14:23 ` [virtio-dev] " Michael S. Tsirkin
2023-06-04 14:48 ` [virtio-dev] " Parav Pandit
2023-06-04 14:53 ` [virtio-dev] " Michael S. Tsirkin
2023-06-04 15:07 ` [virtio-dev] " Parav Pandit
2023-06-04 21:48 ` [virtio-dev] " Michael S. Tsirkin
2023-06-04 23:40 ` [virtio-dev] " Parav Pandit
2023-06-05 5:51 ` [virtio-dev] " Michael S. Tsirkin
2023-06-05 13:27 ` [virtio-dev] " Parav Pandit
2023-06-05 13:50 ` [virtio-dev] " Michael S. Tsirkin
2023-06-05 16:04 ` [virtio-dev] " Parav Pandit
2023-06-05 21:57 ` [virtio-dev] " Michael S. Tsirkin
2023-06-05 22:12 ` Parav Pandit
2023-06-06 11:56 ` Michael S. Tsirkin
2023-06-06 20:15 ` Parav Pandit
2023-06-07 2:27 ` Jason Wang
2023-06-07 3:05 ` Parav Pandit
2023-06-07 6:54 ` Jason Wang
2023-06-07 8:54 ` Michael S. Tsirkin
2023-06-08 14:38 ` Parav Pandit
2023-06-08 14:44 ` Michael S. Tsirkin
2023-06-08 14:53 ` Parav Pandit
2023-06-08 15:03 ` Michael S. Tsirkin
2023-06-08 15:16 ` Parav Pandit
2023-06-08 18:03 ` Michael S. Tsirkin
2023-06-08 18:11 ` Parav Pandit
2023-06-08 18:31 ` Michael S. Tsirkin
2023-06-08 19:00 ` Parav Pandit
2023-06-08 19:03 ` Michael S. Tsirkin
2023-06-08 19:12 ` Parav Pandit
2023-06-09 2:06 ` Jason Wang
2023-06-09 2:29 ` Parav Pandit
2023-06-09 2:42 ` Jason Wang
2023-06-09 2:53 ` Parav Pandit
2023-06-09 2:56 ` Jason Wang
2023-06-09 2:58 ` [virtio-dev] RE: [virtio-comment] " Parav Pandit
2023-06-09 3:02 ` [virtio-dev] " Jason Wang
2023-06-09 3:25 ` [virtio-dev] " Parav Pandit
2023-06-09 6:27 ` [virtio-dev] " Jason Wang
2023-06-09 7:21 ` Michael S. Tsirkin
2023-06-09 17:11 ` [virtio-dev] " Parav Pandit
2023-06-11 0:27 ` [virtio-dev] " Michael S. Tsirkin
2023-06-11 2:08 ` [virtio-dev] " Parav Pandit
2023-06-11 7:14 ` [virtio-dev] " Michael S. Tsirkin
2023-06-11 12:54 ` [virtio-dev] " Parav Pandit
2023-06-11 20:09 ` [virtio-dev] " Michael S. Tsirkin
2023-06-11 20:17 ` [virtio-dev] " Parav Pandit
2023-06-11 23:15 ` [virtio-dev] " Michael S. Tsirkin
2023-06-26 3:46 ` Jason Wang
2023-06-26 3:32 ` Jason Wang
2023-06-26 3:51 ` [virtio-dev] " Parav Pandit
2023-06-27 2:38 ` [virtio-dev] " Jason Wang
2023-06-27 3:17 ` [virtio-dev] " Parav Pandit
2023-06-27 4:33 ` [virtio-dev] " Jason Wang
2023-06-26 3:50 ` Jason Wang
2023-06-26 3:55 ` [virtio-dev] " Parav Pandit
2023-06-26 10:49 ` [virtio-dev] " Michael S. Tsirkin
2023-06-09 7:15 ` Michael S. Tsirkin
2023-06-26 3:59 ` Jason Wang
2023-06-26 4:04 ` [virtio-dev] RE: [virtio-comment] " Parav Pandit
2023-06-27 2:42 ` [virtio-dev] " Jason Wang
2023-06-26 7:13 ` Michael S. Tsirkin
2023-06-07 8:57 ` Michael S. Tsirkin
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=20230604095615-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=david.edmondson@oracle.com \
--cc=jasowang@redhat.com \
--cc=maorg@nvidia.com \
--cc=parav@nvidia.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