* [virtio-dev] [PATCH v10 0/4] admin: Access legacy registers using admin commands
@ 2023-07-06 4:17 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 4:17 UTC (permalink / raw)
To: virtio-comment, mst, cohuck, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
This short series introduces legacy registers access commands for the owner
group member access the legacy registers of the member VFs.
This short series introduces legacy region access commands by the group owner
device for its member devices.
Currently it is applicable to the PCI PF and VF devices. 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.
More details as overview, motivation, use case are further described
below.
Patch summary:
--------------
patch-1 split rows of admin opcode tables by a line
patch-2 fix section numbering
patch-3 add generic legacy region access commands
patch-4 add pci specific definition
It uses the newly introduced administration command facility with 4 new
commands and a new optional command to query the legacy notification region.
Usecase:
--------
1. A hypervisor/system needs to provide transitional
virtio devices to the guest VM at scale of thousands,
typically, one to eight devices per VM.
2. A hypervisor/system needs to provide such devices using a
vendor agnostic driver in the hypervisor system.
3. A hypervisor system prefers to have single stack regardless of
virtio device type (net/blk) and be future compatible with a
single vfio stack using SR-IOV or other scalable device
virtualization technology to map PCI devices to the guest VM.
(as transitional or otherwise)
Motivation/Background:
----------------------
The existing virtio transitional PCI device is missing support for
PCI SR-IOV based devices. Currently it does not work beyond
PCI PF, or as software emulated device in reality. Currently it
has below cited system level limitations:
[a] PCIe spec citation:
VFs do not support I/O Space and thus VF BARs shall not indicate I/O Space.
[b] cpu arch citiation:
Intel 64 and IA-32 Architectures Software Developer’s Manual:
The processor’s I/O address space is separate and distinct from
the physical-memory address space. The I/O address space consists
of 64K individually addressable 8-bit I/O ports, numbered 0 through FFFFH.
[c] PCIe spec citation:
If a bridge implements an I/O address range,...I/O address range will be
aligned to a 4 KB boundary.
Overview:
---------
Above usecase requirements is solved by PCI PF group owner accessing
its group member PCI VFs legacy registers using an admin virtqueue of
the group owner PCI PF.
Two new admin virtqueue commands are added which read/write PCI VF
registers.
Software usage example:
-----------------------
One way to use and map to the guest VM is by using vfio driver
framework in Linux kernel.
+----------------------+
|pci_dev_id = 0x100X |
+---------------|pci_rev_id = 0x0 |-----+
|vfio device |BAR0 = I/O region | |
| |Other attributes | |
| +----------------------+ |
| |
+ +--------------+ +-----------------+ |
| |I/O BAR to AQ | | Other vfio | |
| |rd/wr mapper | | functionalities | |
| +--------------+ +-----------------+ |
| |
+------+-------------------------+-----------+
| |
Legacy region Driver notification
access |
| |
+----+------------+ +----+------------+
| +-----+ | | PCI VF device A |
| | AQ |-------------+---->+-------------+ |
| +-----+ | | | | legacy regs | |
| PCI PF device | | | +-------------+ |
+-----------------+ | +-----------------+
|
| +----+------------+
| | PCI VF device N |
+---->+-------------+ |
| | legacy regs | |
| +-------------+ |
+-----------------+
2. Virtio pci driver to bind to the listed device id and
use it in the host.
3. Use it in a light weight hypervisor to run bare-metal OS.
Please review.
Alternatives considered:
========================
1. Exposing BAR0 as MMIO BAR that follows legacy registers template
Pros:
a. Kind of works with legacy drivers as some of them have used API
which is agnostic to MMIO vs IOBAR.
b. Does not require hypervisor intervantion
Cons:
a. Device reset is extremely hard to implement in device at scale as
driver does not wait for device reset completion
b. Device register width related problems persist that hypervisor if
wishes, it cannot be fixed.
2. Accessing VF registers by tunneling it through new legacy PCI capability
Pros:
a. Self contained, but cannot work with future PCI SIOV devices
Cons:
a. Equally slow as AQ access
b. Still requires new capability for notification access
c. Requires hardware to build low level registers access which is not worth
for long term future
3. Accessing VF notification region using new PF BAR
Cons:
a. Requires hardware to build new PCI steering logic per PF to forward
notification from the PF to VF, requires double the amount of logic
compared to today
b. Requires very large additional PF BAR whose size must be max_Vfs * BAR size.
4. Trapping CVQ, configuration region, LEGACY_HDR
Cons:
a. This does not fullfil the very basic requirement to not trap the
1.x objects (configuration registers, vqs)
b. Requires feature negotiations mediation in hypervisor software
c. Requires constant device type specific knowledge in hypervisor driver
(Does not scale for 30+ device types)
4. F_LEACY_HDR, F_WRITE_MAC
Cons:
a. Requires device support to have read/write mac address which is
hard to implement on every member device.
b. such functionality is duplicate of existing cvq per device.
c. config space is only for the initialization specific purpose.
d. Requires mediation of 1.x objects, which is not good design.
e. Solves only for the net device.
Pros:
a. May work for nested env
conclusion for picking AQ approach:
==================================
1. Overall AQ based access is simpler to implement with combination of
best from software and device so that legacy registers do not get baked
in the device hardware
2. AQ allows hypervisor software to intercept legacy registers and make
corrections if needed
3. Provides trade-off between performance, device complexity vs spec,
while still maintaining passthrough mode for the VFs with minimal
hypervisor intercepts only for legacy registers access
4. AQ mechanism is designed for accessing other member devices registers
as noted in AQ submission, it utilizes the existing infrastructure over
other alternatives.
5. Uses existing driver notification region similar to legacy notification
saves hardware resources
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/167
Signed-off-by: Parav Pandit <parav@nvidia.com>
---
changelog:
v9->v10:
- added white space at end of line
- addressed below comments from Cornelia
- fixed errors related to article
- hardwire to hardwires
- replaced various to all
- added hardwire to zero
- fixed requirements for administration virtqueue section
- added missing articles
- reworded description for notification query command
- grammar fixes
- addressed below comments from Michael
- added description for member group id setting
- reworded device and driver conformance statements
- opcode table description updated
- fixed label for device read command
- length alignment restriction text added
- data length described for read write commands
- notification description added and refined
- reworded text around command specific result and data field usage
v8->v9:
- add missing articles in notify query command
- replaced 'this notification' with 'such a notification'
- addressed below comments from Michael
- dropped 'Region' from the commands
- added 7 reserved pad bytes in config write commands
- rewrote from 'use following structure' to 'field' has the following
struct..
- dropped mentioning to follow struct virtio_admin_cmd.
- added note about command limited to only sriov group type for now
- rewrote the description little differently
v7->v8:
- remove empty line at the end of file
- removed white space at the end
- addressed comments from Michael add link to pci
- renamed region to region_data
- made region_data width to be 16 bytes to cover for 8 bytes offset
- moved generic notification region related normative from pci to
generic section
- addressed comments from Michael
- made bar offset 64-bit
- prefix legacy specific structure with _legacy
- moved generic normative from pci to generic section
- added link to virtio pci capabilities when referring to bar 0
- remove 'should' from generic description
v6->v7:
- addressed several comments from Michael
- use AQ command to query legacy notify region, dropped pci capability
modifications
- moved most part of the text to the generic admin command section
- replace administrative to administration
- replace admin vq citation to admin commands
- added normatives for device and driver side
- made BAR0 to be not used at all when supporting legacy interface
- added normative around BAR0 and SR-IOV extended capability
- grammar corrections
v5->v6:
- fixed previous missed abbreviation of LCC and LD
- added text for the PCI capability for the group member device
v4->v5:
- split pci transport and generic command section to new patch
- removed multiple references to the VF
- written the description of the command as generic with member
and group device terminology
- reflected many section names to remove VF
- split from pci transport specific patch
- split conformance to transport and generic sections
- written the description of the command as generic with member
and group device terminology
- reflected many section names to remove VF
- rename fields from register to region
- avoided abbreviation for legacy, device and config
v3->v4:
- moved noted to the conformance section details in next patch
- removed queue notify address query AQ command on Michael's suggestion,
though it is fine. Instead replaced with extending virtio_pci_notify_cap
to indicate that legacy queue notifications can be done on the
notification location
- fixed spelling errors
- replaced administrative virtqueue to administration virtqueue
- moved legacy interface normative references to legacy conformance
section
v2->v3:
- added new patch to split raws of admin vq opcode table
- adddressed Jason and Michael's comment to split single register
access command to common config and device specific commands.
- dropped the suggetion to introduce enable/disable command as
admin command cap bit already covers it.
- added other alternative design considered and discussed in detail in v0, v1 and v2
v1->v2:
- addressed comments from Michael
- added theory of operation
- grammar corrections
- removed group fields description from individual commands as
it is already present in generic section
- added endianness normative for legacy device registers region
- renamed the file to drop vf and add legacy prefix
- added overview in commit log
- renamed subsection to reflect command
v0->v1:
- addressed comments, suggesetions and ideas from Michael Tsirkin and Jason Wang
- far more simpler design than MMR access
- removed complexities of MMR device ids
- removed complexities of MMR registers and extended capabilities
- dropped adding new extended capabilities because if if they are
added, a pci device still needs to have existing capabilities
in the legacy configuration space and hypervisor driver do not
need to access them
Parav Pandit (4):
admin: Split opcode table rows with a line
admin: Fix section numbering
admin: Add group member legacy register access commands
transport-pci: Introduce group legacy group member config region
access
admin-cmds-legacy-interface.tex | 262 ++++++++++++++++++++++++++++++++
admin.tex | 24 ++-
conformance.tex | 3 +
transport-pci-legacy-regs.tex | 42 +++++
transport-pci.tex | 2 +
5 files changed, 328 insertions(+), 5 deletions(-)
create mode 100644 admin-cmds-legacy-interface.tex
create mode 100644 transport-pci-legacy-regs.tex
--
2.26.2
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] [PATCH v10 0/4] admin: Access legacy registers using admin commands
@ 2023-07-06 4:17 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 4:17 UTC (permalink / raw)
To: virtio-comment, mst, cohuck, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
This short series introduces legacy registers access commands for the owner
group member access the legacy registers of the member VFs.
This short series introduces legacy region access commands by the group owner
device for its member devices.
Currently it is applicable to the PCI PF and VF devices. 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.
More details as overview, motivation, use case are further described
below.
Patch summary:
--------------
patch-1 split rows of admin opcode tables by a line
patch-2 fix section numbering
patch-3 add generic legacy region access commands
patch-4 add pci specific definition
It uses the newly introduced administration command facility with 4 new
commands and a new optional command to query the legacy notification region.
Usecase:
--------
1. A hypervisor/system needs to provide transitional
virtio devices to the guest VM at scale of thousands,
typically, one to eight devices per VM.
2. A hypervisor/system needs to provide such devices using a
vendor agnostic driver in the hypervisor system.
3. A hypervisor system prefers to have single stack regardless of
virtio device type (net/blk) and be future compatible with a
single vfio stack using SR-IOV or other scalable device
virtualization technology to map PCI devices to the guest VM.
(as transitional or otherwise)
Motivation/Background:
----------------------
The existing virtio transitional PCI device is missing support for
PCI SR-IOV based devices. Currently it does not work beyond
PCI PF, or as software emulated device in reality. Currently it
has below cited system level limitations:
[a] PCIe spec citation:
VFs do not support I/O Space and thus VF BARs shall not indicate I/O Space.
[b] cpu arch citiation:
Intel 64 and IA-32 Architectures Software Developer’s Manual:
The processor’s I/O address space is separate and distinct from
the physical-memory address space. The I/O address space consists
of 64K individually addressable 8-bit I/O ports, numbered 0 through FFFFH.
[c] PCIe spec citation:
If a bridge implements an I/O address range,...I/O address range will be
aligned to a 4 KB boundary.
Overview:
---------
Above usecase requirements is solved by PCI PF group owner accessing
its group member PCI VFs legacy registers using an admin virtqueue of
the group owner PCI PF.
Two new admin virtqueue commands are added which read/write PCI VF
registers.
Software usage example:
-----------------------
One way to use and map to the guest VM is by using vfio driver
framework in Linux kernel.
+----------------------+
|pci_dev_id = 0x100X |
+---------------|pci_rev_id = 0x0 |-----+
|vfio device |BAR0 = I/O region | |
| |Other attributes | |
| +----------------------+ |
| |
+ +--------------+ +-----------------+ |
| |I/O BAR to AQ | | Other vfio | |
| |rd/wr mapper | | functionalities | |
| +--------------+ +-----------------+ |
| |
+------+-------------------------+-----------+
| |
Legacy region Driver notification
access |
| |
+----+------------+ +----+------------+
| +-----+ | | PCI VF device A |
| | AQ |-------------+---->+-------------+ |
| +-----+ | | | | legacy regs | |
| PCI PF device | | | +-------------+ |
+-----------------+ | +-----------------+
|
| +----+------------+
| | PCI VF device N |
+---->+-------------+ |
| | legacy regs | |
| +-------------+ |
+-----------------+
2. Virtio pci driver to bind to the listed device id and
use it in the host.
3. Use it in a light weight hypervisor to run bare-metal OS.
Please review.
Alternatives considered:
========================
1. Exposing BAR0 as MMIO BAR that follows legacy registers template
Pros:
a. Kind of works with legacy drivers as some of them have used API
which is agnostic to MMIO vs IOBAR.
b. Does not require hypervisor intervantion
Cons:
a. Device reset is extremely hard to implement in device at scale as
driver does not wait for device reset completion
b. Device register width related problems persist that hypervisor if
wishes, it cannot be fixed.
2. Accessing VF registers by tunneling it through new legacy PCI capability
Pros:
a. Self contained, but cannot work with future PCI SIOV devices
Cons:
a. Equally slow as AQ access
b. Still requires new capability for notification access
c. Requires hardware to build low level registers access which is not worth
for long term future
3. Accessing VF notification region using new PF BAR
Cons:
a. Requires hardware to build new PCI steering logic per PF to forward
notification from the PF to VF, requires double the amount of logic
compared to today
b. Requires very large additional PF BAR whose size must be max_Vfs * BAR size.
4. Trapping CVQ, configuration region, LEGACY_HDR
Cons:
a. This does not fullfil the very basic requirement to not trap the
1.x objects (configuration registers, vqs)
b. Requires feature negotiations mediation in hypervisor software
c. Requires constant device type specific knowledge in hypervisor driver
(Does not scale for 30+ device types)
4. F_LEACY_HDR, F_WRITE_MAC
Cons:
a. Requires device support to have read/write mac address which is
hard to implement on every member device.
b. such functionality is duplicate of existing cvq per device.
c. config space is only for the initialization specific purpose.
d. Requires mediation of 1.x objects, which is not good design.
e. Solves only for the net device.
Pros:
a. May work for nested env
conclusion for picking AQ approach:
==================================
1. Overall AQ based access is simpler to implement with combination of
best from software and device so that legacy registers do not get baked
in the device hardware
2. AQ allows hypervisor software to intercept legacy registers and make
corrections if needed
3. Provides trade-off between performance, device complexity vs spec,
while still maintaining passthrough mode for the VFs with minimal
hypervisor intercepts only for legacy registers access
4. AQ mechanism is designed for accessing other member devices registers
as noted in AQ submission, it utilizes the existing infrastructure over
other alternatives.
5. Uses existing driver notification region similar to legacy notification
saves hardware resources
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/167
Signed-off-by: Parav Pandit <parav@nvidia.com>
---
changelog:
v9->v10:
- added white space at end of line
- addressed below comments from Cornelia
- fixed errors related to article
- hardwire to hardwires
- replaced various to all
- added hardwire to zero
- fixed requirements for administration virtqueue section
- added missing articles
- reworded description for notification query command
- grammar fixes
- addressed below comments from Michael
- added description for member group id setting
- reworded device and driver conformance statements
- opcode table description updated
- fixed label for device read command
- length alignment restriction text added
- data length described for read write commands
- notification description added and refined
- reworded text around command specific result and data field usage
v8->v9:
- add missing articles in notify query command
- replaced 'this notification' with 'such a notification'
- addressed below comments from Michael
- dropped 'Region' from the commands
- added 7 reserved pad bytes in config write commands
- rewrote from 'use following structure' to 'field' has the following
struct..
- dropped mentioning to follow struct virtio_admin_cmd.
- added note about command limited to only sriov group type for now
- rewrote the description little differently
v7->v8:
- remove empty line at the end of file
- removed white space at the end
- addressed comments from Michael add link to pci
- renamed region to region_data
- made region_data width to be 16 bytes to cover for 8 bytes offset
- moved generic notification region related normative from pci to
generic section
- addressed comments from Michael
- made bar offset 64-bit
- prefix legacy specific structure with _legacy
- moved generic normative from pci to generic section
- added link to virtio pci capabilities when referring to bar 0
- remove 'should' from generic description
v6->v7:
- addressed several comments from Michael
- use AQ command to query legacy notify region, dropped pci capability
modifications
- moved most part of the text to the generic admin command section
- replace administrative to administration
- replace admin vq citation to admin commands
- added normatives for device and driver side
- made BAR0 to be not used at all when supporting legacy interface
- added normative around BAR0 and SR-IOV extended capability
- grammar corrections
v5->v6:
- fixed previous missed abbreviation of LCC and LD
- added text for the PCI capability for the group member device
v4->v5:
- split pci transport and generic command section to new patch
- removed multiple references to the VF
- written the description of the command as generic with member
and group device terminology
- reflected many section names to remove VF
- split from pci transport specific patch
- split conformance to transport and generic sections
- written the description of the command as generic with member
and group device terminology
- reflected many section names to remove VF
- rename fields from register to region
- avoided abbreviation for legacy, device and config
v3->v4:
- moved noted to the conformance section details in next patch
- removed queue notify address query AQ command on Michael's suggestion,
though it is fine. Instead replaced with extending virtio_pci_notify_cap
to indicate that legacy queue notifications can be done on the
notification location
- fixed spelling errors
- replaced administrative virtqueue to administration virtqueue
- moved legacy interface normative references to legacy conformance
section
v2->v3:
- added new patch to split raws of admin vq opcode table
- adddressed Jason and Michael's comment to split single register
access command to common config and device specific commands.
- dropped the suggetion to introduce enable/disable command as
admin command cap bit already covers it.
- added other alternative design considered and discussed in detail in v0, v1 and v2
v1->v2:
- addressed comments from Michael
- added theory of operation
- grammar corrections
- removed group fields description from individual commands as
it is already present in generic section
- added endianness normative for legacy device registers region
- renamed the file to drop vf and add legacy prefix
- added overview in commit log
- renamed subsection to reflect command
v0->v1:
- addressed comments, suggesetions and ideas from Michael Tsirkin and Jason Wang
- far more simpler design than MMR access
- removed complexities of MMR device ids
- removed complexities of MMR registers and extended capabilities
- dropped adding new extended capabilities because if if they are
added, a pci device still needs to have existing capabilities
in the legacy configuration space and hypervisor driver do not
need to access them
Parav Pandit (4):
admin: Split opcode table rows with a line
admin: Fix section numbering
admin: Add group member legacy register access commands
transport-pci: Introduce group legacy group member config region
access
admin-cmds-legacy-interface.tex | 262 ++++++++++++++++++++++++++++++++
admin.tex | 24 ++-
conformance.tex | 3 +
transport-pci-legacy-regs.tex | 42 +++++
transport-pci.tex | 2 +
5 files changed, 328 insertions(+), 5 deletions(-)
create mode 100644 admin-cmds-legacy-interface.tex
create mode 100644 transport-pci-legacy-regs.tex
--
2.26.2
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] [PATCH v10 1/4] admin: Split opcode table rows with a line
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 4:17 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 4:17 UTC (permalink / raw)
To: virtio-comment, mst, cohuck, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
Currently all opcode appears to be in a single row.
Separate them with a line similar to other tables.
Signed-off-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
---
changelog:
v2->v3:
- new patch
---
admin.tex | 2 ++
1 file changed, 2 insertions(+)
diff --git a/admin.tex b/admin.tex
index 2efd4d7..e51f9e6 100644
--- a/admin.tex
+++ b/admin.tex
@@ -114,7 +114,9 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
opcode & Name & Command Description \\
\hline \hline
0x0000 & VIRTIO_ADMIN_CMD_LIST_QUERY & Provides to driver list of commands supported for this group type \\
+\hline
0x0001 & VIRTIO_ADMIN_CMD_LIST_USE & Provides to device list of commands used for this group type \\
+\hline
0x0002 - 0x7FFF & - & Commands using \field{struct virtio_admin_cmd} \\
\hline
0x8000 - 0xFFFF & - & Reserved for future commands (possibly using a different structure) \\
--
2.26.2
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 78+ messages in thread
* [virtio-comment] [PATCH v10 1/4] admin: Split opcode table rows with a line
@ 2023-07-06 4:17 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 4:17 UTC (permalink / raw)
To: virtio-comment, mst, cohuck, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
Currently all opcode appears to be in a single row.
Separate them with a line similar to other tables.
Signed-off-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
---
changelog:
v2->v3:
- new patch
---
admin.tex | 2 ++
1 file changed, 2 insertions(+)
diff --git a/admin.tex b/admin.tex
index 2efd4d7..e51f9e6 100644
--- a/admin.tex
+++ b/admin.tex
@@ -114,7 +114,9 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
opcode & Name & Command Description \\
\hline \hline
0x0000 & VIRTIO_ADMIN_CMD_LIST_QUERY & Provides to driver list of commands supported for this group type \\
+\hline
0x0001 & VIRTIO_ADMIN_CMD_LIST_USE & Provides to device list of commands used for this group type \\
+\hline
0x0002 - 0x7FFF & - & Commands using \field{struct virtio_admin_cmd} \\
\hline
0x8000 - 0xFFFF & - & Reserved for future commands (possibly using a different structure) \\
--
2.26.2
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply related [flat|nested] 78+ messages in thread
* [virtio-dev] [PATCH v10 2/4] admin: Fix section numbering
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 4:17 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 4:17 UTC (permalink / raw)
To: virtio-comment, mst, cohuck, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
Requirements are put one additional level down. Fix it.
Signed-off-by: Parav Pandit <parav@nvidia.com>
---
changelog:
v9->v10:
- addressed comments from Cornelia
- fixed requirements for administration virtqueue section
v4->v5:
- new patch
---
admin.tex | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/admin.tex b/admin.tex
index e51f9e6..b0a1a91 100644
--- a/admin.tex
+++ b/admin.tex
@@ -286,7 +286,7 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
supporting multiple group types, the list of supported commands
might differ between different group types.
-\devicenormative{\paragraph}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands}
+\devicenormative{\subsubsection}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands}
The device MUST validate \field{opcode}, \field{group_type} and
\field{group_member_id}, and if any of these has an invalid or
@@ -378,7 +378,7 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
\field{VF Enable} refer to registers within the SR-IOV Extended
Capability as specified by \hyperref[intro:PCIe]{[PCIe]}.
-\drivernormative{\paragraph}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands}
+\drivernormative{\subsubsection}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands}
The driver MAY discover whether device supports a specific group type
by issuing VIRTIO_ADMIN_CMD_LIST_QUERY with the matching
@@ -506,7 +506,7 @@ \section{Administration Virtqueues}\label{sec:Basic Facilities of a Virtio Devic
tail of a structure, with the driver/device using the full
structure without concern for versioning.
-\devicenormative{\paragraph}{Group administration commands}{Basic Facilities of a Virtio Device / Administration virtqueues}
+\devicenormative{\subsection}{Group administration commands}{Basic Facilities of a Virtio Device / Administration virtqueues}
The device MUST support device-readable and device-writeable buffers
shorter than described in this specification, by
@@ -555,7 +555,7 @@ \section{Administration Virtqueues}\label{sec:Basic Facilities of a Virtio Devic
or VIRTIO_ADMIN_STATUS_ENOMEM, then the command MUST NOT
have any side effects, making it safe to retry.
-\drivernormative{\paragraph}{Group administration commands}{Basic Facilities of a Virtio Device / Administration virtqueues}
+\drivernormative{\subsection}{Group administration commands}{Basic Facilities of a Virtio Device / Administration virtqueues}
The driver MAY supply device-readable or device-writeable parts
of \field{struct virtio_admin_cmd} that are longer than described in
--
2.26.2
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 78+ messages in thread
* [virtio-comment] [PATCH v10 2/4] admin: Fix section numbering
@ 2023-07-06 4:17 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 4:17 UTC (permalink / raw)
To: virtio-comment, mst, cohuck, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
Requirements are put one additional level down. Fix it.
Signed-off-by: Parav Pandit <parav@nvidia.com>
---
changelog:
v9->v10:
- addressed comments from Cornelia
- fixed requirements for administration virtqueue section
v4->v5:
- new patch
---
admin.tex | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/admin.tex b/admin.tex
index e51f9e6..b0a1a91 100644
--- a/admin.tex
+++ b/admin.tex
@@ -286,7 +286,7 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
supporting multiple group types, the list of supported commands
might differ between different group types.
-\devicenormative{\paragraph}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands}
+\devicenormative{\subsubsection}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands}
The device MUST validate \field{opcode}, \field{group_type} and
\field{group_member_id}, and if any of these has an invalid or
@@ -378,7 +378,7 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
\field{VF Enable} refer to registers within the SR-IOV Extended
Capability as specified by \hyperref[intro:PCIe]{[PCIe]}.
-\drivernormative{\paragraph}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands}
+\drivernormative{\subsubsection}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands}
The driver MAY discover whether device supports a specific group type
by issuing VIRTIO_ADMIN_CMD_LIST_QUERY with the matching
@@ -506,7 +506,7 @@ \section{Administration Virtqueues}\label{sec:Basic Facilities of a Virtio Devic
tail of a structure, with the driver/device using the full
structure without concern for versioning.
-\devicenormative{\paragraph}{Group administration commands}{Basic Facilities of a Virtio Device / Administration virtqueues}
+\devicenormative{\subsection}{Group administration commands}{Basic Facilities of a Virtio Device / Administration virtqueues}
The device MUST support device-readable and device-writeable buffers
shorter than described in this specification, by
@@ -555,7 +555,7 @@ \section{Administration Virtqueues}\label{sec:Basic Facilities of a Virtio Devic
or VIRTIO_ADMIN_STATUS_ENOMEM, then the command MUST NOT
have any side effects, making it safe to retry.
-\drivernormative{\paragraph}{Group administration commands}{Basic Facilities of a Virtio Device / Administration virtqueues}
+\drivernormative{\subsection}{Group administration commands}{Basic Facilities of a Virtio Device / Administration virtqueues}
The driver MAY supply device-readable or device-writeable parts
of \field{struct virtio_admin_cmd} that are longer than described in
--
2.26.2
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply related [flat|nested] 78+ messages in thread
* [virtio-dev] [PATCH v10 3/4] admin: Add group member legacy register access commands
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 4:17 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 4:17 UTC (permalink / raw)
To: virtio-comment, mst, cohuck, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
Introduce group member legacy common configuration and legacy device
configuration access read/write commands.
Group member legacy registers access commands enable group owner driver
software to access legacy registers on behalf of the guest virtual
machine.
Usecase:
========
1. A hypervisor/system needs to provide transitional
virtio devices to the guest VM at scale of thousands,
typically, one to eight devices per VM.
2. A hypervisor/system needs to provide such devices using a
vendor agnostic driver in the hypervisor system.
3. A hypervisor system prefers to have single stack regardless of
virtio device type (net/blk) and be future compatible with a
single vfio stack using SR-IOV or other scalable device
virtualization technology to map PCI devices to the guest VM.
(as transitional or otherwise)
Motivation/Background:
=====================
The existing virtio transitional PCI device is missing support for
PCI SR-IOV based devices. Currently it does not work beyond
PCI PF, or as software emulated device in reality. Currently it
has below cited system level limitations:
[a] PCIe spec citation:
VFs do not support I/O Space and thus VF BARs shall not indicate I/O Space.
[b] cpu arch citiation:
Intel 64 and IA-32 Architectures Software Developer’s Manual:
The processor’s I/O address space is separate and distinct from
the physical-memory address space. The I/O address space consists
of 64K individually addressable 8-bit I/O ports, numbered 0 through FFFFH.
[c] PCIe spec citation:
If a bridge implements an I/O address range,...I/O address range will be
aligned to a 4 KB boundary.
Overview:
=========
Above usecase requirements is solved by PCI PF group owner accessing
its group member PCI VFs legacy registers using the administration
commands of the group owner PCI PF.
Two types of administration commands are added which read/write PCI VF
registers.
Software usage example:
=======================
1. One way to use and map to the guest VM is by using vfio driver
framework in Linux kernel.
+----------------------+
|pci_dev_id = 0x100X |
+---------------|pci_rev_id = 0x0 |-----+
|vfio device |BAR0 = I/O region | |
| |Other attributes | |
| +----------------------+ |
| |
+ +--------------+ +-----------------+ |
| |I/O BAR to AQ | | Other vfio | |
| |rd/wr mapper& | | functionalities | |
| | forwarder | | | |
| +--------------+ +-----------------+ |
| |
+------+-------------------------+-----------+
| |
Config region |
access Driver notifications
| |
+----+------------+ +----+------------+
| +-----+ | | PCI VF device A |
| | AQ |-------------+---->+-------------+ |
| +-----+ | | | | legacy regs | |
| PCI PF device | | | +-------------+ |
+-----------------+ | +-----------------+
|
| +----+------------+
| | PCI VF device N |
+---->+-------------+ |
| | legacy regs | |
| +-------------+ |
+-----------------+
2. Continue to use the virtio pci driver to bind to the
listed device id and use it as in the host.
3. Use it in a light weight hypervisor to run bare-metal OS.
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/167
Signed-off-by: Parav Pandit <parav@nvidia.com>
---
changelog:
v9->v10:
- added white space at end of line
- addressed below comments from Cornelia
- added missing articles
- reworded description for notification query command
- grammar fixes
- addressed below comments from Michael
- added description for member group id setting
- reworded device and driver conformance statements
- opcode table description updated
- fixed label for device read command
- length alignment restriction text added
- data length described for read write commands
- notification description added and refined
- reworded text around command specific result and data field usage
v8->v9:
- add missing articles in notify query command
- replaced 'this notification' with 'such a notification'
- addressed below comments from Michael
- dropped 'Region' from the commands
- added 7 reserved pad bytes in config write commands
- rewrote from 'use following structure' to 'field' has the following
struct..
- dropped mentioning to follow struct virtio_admin_cmd.
- added note about command limited to only sriov group type for now
- rewrote the description little differently
v7->v8:
- remove empty line at the end of file
- removed white space at the end
- addressed comments from Michael add link to pci
- renamed region to region_data
- made region_data width to be 16 bytes to cover for 8 bytes offset
- moved generic notification region related normative from pci to
generic section
v6->v7:
- changed administrative to administration
- renamed admin-access.tex to admin-interface.tex
- large rewrite ad generic admin commands instead of pci
- added theory of operation section
- added driver notification region query command
v5->v6:
- fixed previous missed abbreviation of LCC and LD
v4->v5:
- split from pci transport specific patch
- split conformance to transport and generic sections
- written the description of the command as generic with member
and group device terminology
- reflected many section names to remove VF
- rename fields from register to region
- avoided abbreviation for legacy, device and config
---
admin-cmds-legacy-interface.tex | 261 ++++++++++++++++++++++++++++++++
admin.tex | 14 +-
conformance.tex | 2 +
3 files changed, 276 insertions(+), 1 deletion(-)
create mode 100644 admin-cmds-legacy-interface.tex
diff --git a/admin-cmds-legacy-interface.tex b/admin-cmds-legacy-interface.tex
new file mode 100644
index 0000000..dd01c0a
--- /dev/null
+++ b/admin-cmds-legacy-interface.tex
@@ -0,0 +1,261 @@
+\subsubsection{Legacy Interfaces}\label{sec:Basic Facilities of a Virtio Device / Device groups / Group
+administration commands / Legacy Interface}
+
+In some systems, there is a need to support utilizing the legacy driver with
+the device that do not directly support the legacy interface. In such scenarios,
+a group owner device can provide the legacy interface functionality for the
+group member devices. The driver of an owner device can then access the legacy
+interface of a member device on behalf of the legacy member device driver.
+
+For example, with the SR-IOV group type, group members (VFs) can not present
+the legacy interface in an I/O BAR in BAR0 as expected by the legacy pci driver.
+If the legacy driver is running inside a virtual machine, the hypervisor
+executing the virtual machine can present a virtual device with an I/O BAR in
+BAR0. The hypervisor intercepts the legacy driver accesses to this I/O BAR and
+forwards them to the group owner device (PF) using group administration commands.
+
+The following commands support such legacy interface functionality:
+
+\begin{enumerate}
+\item Legacy Common Configuration Write Command
+\item Legacy Common Configuration Read Command
+\item Legacy Device Configuration Write Command
+\item Legacy Device Configuration Read Command
+\end{enumerate}
+
+These commands are currently only defined for the SR-IOV group type and
+have, generally, the same effect as member device accesses through a legacy
+interface listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Legacy Interfaces: A Note on PCI Device Layout} except that little endian format is assumed unconditionally.
+
+\paragraph{Legacy Common Configuration Write Command}\label{par:Basic Facilities of a Virtio Device / Device groups / Group
+administration commands / Legacy Interface / Legacy Common Configuration Write Command}
+
+This command has the same effect as writing into the virtio common configuration
+structure through the legacy interface. The \field{command_specific_data} is in
+the format \field{struct virtio_admin_cmd_legacy_common_cfg_wr_data} describing
+the access to be performed.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_common_cfg_wr_data {
+ u8 offset; /* Starting byte offset within the common configuration structure to write */
+ u8 reserved[7];
+ u8 data[];
+};
+\end{lstlisting}
+
+The driver sets command \field{opcode} to VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE.
+The driver sets \field{group_member_id} which refers to the member device to be
+accessed. The driver sets \field{offset} which refers to the offset to write within the
+virtio common configuration structure, and excluding the device-specific configuration.
+
+The length of the data to write is simply the length of \field{data}.
+
+No length or alignment restrictions are placed on the value of the
+\field{offset} and the length of the \field{data}, except that the resulting
+access refers to a single field and is completely within the virtio common
+configuration structure, excluding the device-specific configuration.
+
+This command has no command specific result.
+
+\paragraph{Legacy Common Configuration Read Command}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Common Configuration Read Command}
+
+This command has the same effect as reading from the virtio common configuration
+structure through the legacy interface. The \field{command_specific_data} is in
+the format \field{struct virtio_admin_cmd_legacy_common_cfg_rd_data} describing
+the access to be performed.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_common_cfg_rd_data {
+ u8 offset; /* Starting byte offset within the common configuration structure to read */
+};
+\end{lstlisting}
+
+The driver sets command \field{opcode} to VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ.
+
+The driver sets \field{offset} which refers to the offset to read from the
+virtio common configuration structure, and excluding the device-specific
+configuration.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_common_cfg_rd_result {
+ u8 data[];
+};
+\end{lstlisting}
+
+When the command completes successfully, \field{command_specific_result}
+is in the format of \field{struct virtio_admin_cmd_legacy_common_cfg_rd_result}
+returned by the device.
+
+The length of the data read is simply the length of \field{data}.
+
+\paragraph{Legacy Device Configuration Write Command}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Device Configuration Write Command}
+
+This command has the same effect as writing into the virtio device-specific
+configuration through the legacy interface. The \field{command_specific_data} is in
+the format \field{struct virtio_admin_cmd_legacy_dev_reg_wr_data} describing
+the access to be performed.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_dev_reg_wr_data {
+ u8 offset; /* Starting byte offset within the device-specific configuration to write */
+ u8 reserved[7];
+ u8 data[];
+};
+\end{lstlisting}
+
+The driver sets command \field{opcode} to VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE.
+The driver sets \field{group_member_id} which refers to the member device to be
+accessed. The driver sets \field{offset} which refers to the offset to write
+within the virtio device-specific configuration.
+
+The length of the data to write is simply the length of \field{data}.
+
+No length or alignment restrictions are placed on the value of the
+\field{offset} and the length of the \field{data}, except that the resulting
+access refers to a single field and is completely within the device-specific
+configuration.
+
+This command has no command specific result.
+
+\paragraph{Legacy Device Configuration Read Command}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Device Configuration Read Command}
+
+This command has the same effect as reading from the virtio device-specific
+configuration through the legacy interface. The \field{command_specific_data} is in
+the format \field{struct virtio_admin_cmd_legacy_common_cfg_rd_data} describing
+the access to be performed.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_dev_cfg_rd_data {
+ u8 offset; /* Starting byte offset within the device-specific configuration to read */
+};
+\end{lstlisting}
+
+The driver sets command \field{opcode} to VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ.
+The driver sets \field{group_member_id} which refers to the member device to be
+accessed. The driver sets \field{offset} which refers to the offset to read from
+the virtio device-specific configuration.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_dev_reg_rd_result {
+ u8 data[];
+};
+\end{lstlisting}
+
+When the command completes successfully, \field{command_specific_result} is in
+the format of \field{struct virtio_admin_cmd_legacy_dev_reg_rd_result}
+returned by the device.
+
+The length of the data read is simply the length of \field{data}.
+
+\paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Driver Notifications}
+
+If the group owner device or the group member device support driver
+notifications via a memory-mapped operation or I/O operation, these
+notifications are sent to the device via accessing such a notification region
+using a memory or I/O operation instead of sending the notifications through
+the admistration command.
+
+The driver of the owner device can send a driver notification to the member
+device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
+\field{offset} matching \field{Queue Notify} and the \field{data} containing
+the virtqueue index to be notified.
+
+However, as many administration commands are used for slow path configuration,
+a separate fast path mechanism for such notifications is desired. For the
+SR-IOV group type, the optional command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
+addresses this need by returning to the driver one or more addresses which to
+be used to send such driver notifications.
+
+The driver sets command \field{opcode} to VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY.
+The driver sets \field{group_member_id} which refers to the member device to be
+accessed. This command does not use \field{command_specific_data}.
+
+When the command completes successfully, \field{command_specific_result}
+is in the format of \field{struct virtio_admin_cmd_legacy_notify_query_result}.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_notify_query_entry {
+ u8 data[16];
+};
+
+struct virtio_admin_cmd_legacy_notify_query_result {
+ struct virtio_virtio_admin_cmd_legacy_notify_query_entry entries[];
+};
+\end{lstlisting}
+
+The driver picks the suitable entry when multiple entries are supplied
+by the device.
+
+Refer to the specific transport section for the definition of the
+\field{data}.
+
+This command is currently only defined for the SR-IOV group type.
+
+\devicenormative{\paragraph}{Legacy Interface}{Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface}
+
+A device MUST either support all of, or none of
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ commands.
+
+For VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ commands, the device MUST decode and
+encode (respectively) the value of the \field{data} using the little-endian
+format.
+
+The device MUST fail VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ commands where the value of the
+\field{offset} and the length of the \field{data} does not refer to a
+refer to a single field or is not completely within the virtio common
+configuration structure excluding the device-specific configuration.
+
+The device MUST fail VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ commands where the value of the
+\field{offset} and the length of the \field{data} does not refer to a
+refer to a single field or is not completely within the
+device-specific configuration.
+
+If the device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY it MUST
+also support all of VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ.
+
+The command VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE MUST have the same effect
+as writing into the virtio common configuration structure through the legacy
+interface.
+
+The command VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ MUST have the same effect as
+reading from the virtio common configuration structure through the legacy
+interface.
+
+The command VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE MUST have the same effect as
+writing into the virtio device configuration structure through the legacy
+interface.
+
+The command VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ MUST have the same effect as
+reading from the virtio device configuration structure through the legacy
+interface.
+
+\drivernormative{\paragraph}{Legacy Interface}{Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface}
+
+For VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ commands, the driver MUST encode and
+decod3 (respectively) the value of the \field{data} using the little-endian
+format.
+
+For VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ commands the driver SHOULD set
+\field{offset} and the length of the \field{data} to refer to a
+a single field within the virtio common configuration structure excluding
+the device-specific configuration.
+
+For VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ commands the driver SHOULD set
+\field{offset} and the length of the \field{data} to refer to a
+a single field within the virtio device-specific configuration.
+
+The group member driver SHOULD use the notification region supplied by the group
+owner device to send driver notifications to the device if
+VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY is supported.
diff --git a/admin.tex b/admin.tex
index b0a1a91..e2134e1 100644
--- a/admin.tex
+++ b/admin.tex
@@ -117,7 +117,17 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
\hline
0x0001 & VIRTIO_ADMIN_CMD_LIST_USE & Provides to device list of commands used for this group type \\
\hline
-0x0002 - 0x7FFF & - & Commands using \field{struct virtio_admin_cmd} \\
+0x0002 & VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE & Writes into the legacy common configuration structure \\
+\hline
+0x0003 & VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ & Reads from the legacy common configuration structure \\
+\hline
+0x0004 & VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE & Writes into the legacy device configuration structure \\
+\hline
+0x0005 & VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ & Reads into the legacy device configuration structure \\
+\hline
+0x0006 & VIRTIO_ADMIN_CMD_LEGACY_DEV_NOTIFY_QUERY & Query the notification region \\
+\hline
+0x0007 - 0x7FFF & - & Commands using \field{struct virtio_admin_cmd} \\
\hline
0x8000 - 0xFFFF & - & Reserved for future commands (possibly using a different structure) \\
\hline
@@ -286,6 +296,8 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
supporting multiple group types, the list of supported commands
might differ between different group types.
+\input{admin-cmds-legacy-interface.tex}
+
\devicenormative{\subsubsection}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands}
The device MUST validate \field{opcode}, \field{group_type} and
diff --git a/conformance.tex b/conformance.tex
index 01ccd69..dc00e84 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -260,6 +260,8 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\item Section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Legacy Interfaces: A Note on Virtqueue Layout}
\item Section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Legacy Interfaces: A Note on Virtqueue Endianness}
\item Section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Message Framing / Legacy Interface: Message Framing}
+\item Section \ref{devicenormative:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface}
+\item Section \ref{drivernormative:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface}
\item Section \ref{sec:General Initialization And Device Operation / Device Initialization / Legacy Interface: Device Initialization}
\item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Discovery / Legacy Interfaces: A Note on PCI Device Discovery}
\item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Legacy Interfaces: A Note on PCI Device Layout}
--
2.26.2
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 78+ messages in thread
* [virtio-comment] [PATCH v10 3/4] admin: Add group member legacy register access commands
@ 2023-07-06 4:17 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 4:17 UTC (permalink / raw)
To: virtio-comment, mst, cohuck, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
Introduce group member legacy common configuration and legacy device
configuration access read/write commands.
Group member legacy registers access commands enable group owner driver
software to access legacy registers on behalf of the guest virtual
machine.
Usecase:
========
1. A hypervisor/system needs to provide transitional
virtio devices to the guest VM at scale of thousands,
typically, one to eight devices per VM.
2. A hypervisor/system needs to provide such devices using a
vendor agnostic driver in the hypervisor system.
3. A hypervisor system prefers to have single stack regardless of
virtio device type (net/blk) and be future compatible with a
single vfio stack using SR-IOV or other scalable device
virtualization technology to map PCI devices to the guest VM.
(as transitional or otherwise)
Motivation/Background:
=====================
The existing virtio transitional PCI device is missing support for
PCI SR-IOV based devices. Currently it does not work beyond
PCI PF, or as software emulated device in reality. Currently it
has below cited system level limitations:
[a] PCIe spec citation:
VFs do not support I/O Space and thus VF BARs shall not indicate I/O Space.
[b] cpu arch citiation:
Intel 64 and IA-32 Architectures Software Developer’s Manual:
The processor’s I/O address space is separate and distinct from
the physical-memory address space. The I/O address space consists
of 64K individually addressable 8-bit I/O ports, numbered 0 through FFFFH.
[c] PCIe spec citation:
If a bridge implements an I/O address range,...I/O address range will be
aligned to a 4 KB boundary.
Overview:
=========
Above usecase requirements is solved by PCI PF group owner accessing
its group member PCI VFs legacy registers using the administration
commands of the group owner PCI PF.
Two types of administration commands are added which read/write PCI VF
registers.
Software usage example:
=======================
1. One way to use and map to the guest VM is by using vfio driver
framework in Linux kernel.
+----------------------+
|pci_dev_id = 0x100X |
+---------------|pci_rev_id = 0x0 |-----+
|vfio device |BAR0 = I/O region | |
| |Other attributes | |
| +----------------------+ |
| |
+ +--------------+ +-----------------+ |
| |I/O BAR to AQ | | Other vfio | |
| |rd/wr mapper& | | functionalities | |
| | forwarder | | | |
| +--------------+ +-----------------+ |
| |
+------+-------------------------+-----------+
| |
Config region |
access Driver notifications
| |
+----+------------+ +----+------------+
| +-----+ | | PCI VF device A |
| | AQ |-------------+---->+-------------+ |
| +-----+ | | | | legacy regs | |
| PCI PF device | | | +-------------+ |
+-----------------+ | +-----------------+
|
| +----+------------+
| | PCI VF device N |
+---->+-------------+ |
| | legacy regs | |
| +-------------+ |
+-----------------+
2. Continue to use the virtio pci driver to bind to the
listed device id and use it as in the host.
3. Use it in a light weight hypervisor to run bare-metal OS.
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/167
Signed-off-by: Parav Pandit <parav@nvidia.com>
---
changelog:
v9->v10:
- added white space at end of line
- addressed below comments from Cornelia
- added missing articles
- reworded description for notification query command
- grammar fixes
- addressed below comments from Michael
- added description for member group id setting
- reworded device and driver conformance statements
- opcode table description updated
- fixed label for device read command
- length alignment restriction text added
- data length described for read write commands
- notification description added and refined
- reworded text around command specific result and data field usage
v8->v9:
- add missing articles in notify query command
- replaced 'this notification' with 'such a notification'
- addressed below comments from Michael
- dropped 'Region' from the commands
- added 7 reserved pad bytes in config write commands
- rewrote from 'use following structure' to 'field' has the following
struct..
- dropped mentioning to follow struct virtio_admin_cmd.
- added note about command limited to only sriov group type for now
- rewrote the description little differently
v7->v8:
- remove empty line at the end of file
- removed white space at the end
- addressed comments from Michael add link to pci
- renamed region to region_data
- made region_data width to be 16 bytes to cover for 8 bytes offset
- moved generic notification region related normative from pci to
generic section
v6->v7:
- changed administrative to administration
- renamed admin-access.tex to admin-interface.tex
- large rewrite ad generic admin commands instead of pci
- added theory of operation section
- added driver notification region query command
v5->v6:
- fixed previous missed abbreviation of LCC and LD
v4->v5:
- split from pci transport specific patch
- split conformance to transport and generic sections
- written the description of the command as generic with member
and group device terminology
- reflected many section names to remove VF
- rename fields from register to region
- avoided abbreviation for legacy, device and config
---
admin-cmds-legacy-interface.tex | 261 ++++++++++++++++++++++++++++++++
admin.tex | 14 +-
conformance.tex | 2 +
3 files changed, 276 insertions(+), 1 deletion(-)
create mode 100644 admin-cmds-legacy-interface.tex
diff --git a/admin-cmds-legacy-interface.tex b/admin-cmds-legacy-interface.tex
new file mode 100644
index 0000000..dd01c0a
--- /dev/null
+++ b/admin-cmds-legacy-interface.tex
@@ -0,0 +1,261 @@
+\subsubsection{Legacy Interfaces}\label{sec:Basic Facilities of a Virtio Device / Device groups / Group
+administration commands / Legacy Interface}
+
+In some systems, there is a need to support utilizing the legacy driver with
+the device that do not directly support the legacy interface. In such scenarios,
+a group owner device can provide the legacy interface functionality for the
+group member devices. The driver of an owner device can then access the legacy
+interface of a member device on behalf of the legacy member device driver.
+
+For example, with the SR-IOV group type, group members (VFs) can not present
+the legacy interface in an I/O BAR in BAR0 as expected by the legacy pci driver.
+If the legacy driver is running inside a virtual machine, the hypervisor
+executing the virtual machine can present a virtual device with an I/O BAR in
+BAR0. The hypervisor intercepts the legacy driver accesses to this I/O BAR and
+forwards them to the group owner device (PF) using group administration commands.
+
+The following commands support such legacy interface functionality:
+
+\begin{enumerate}
+\item Legacy Common Configuration Write Command
+\item Legacy Common Configuration Read Command
+\item Legacy Device Configuration Write Command
+\item Legacy Device Configuration Read Command
+\end{enumerate}
+
+These commands are currently only defined for the SR-IOV group type and
+have, generally, the same effect as member device accesses through a legacy
+interface listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Legacy Interfaces: A Note on PCI Device Layout} except that little endian format is assumed unconditionally.
+
+\paragraph{Legacy Common Configuration Write Command}\label{par:Basic Facilities of a Virtio Device / Device groups / Group
+administration commands / Legacy Interface / Legacy Common Configuration Write Command}
+
+This command has the same effect as writing into the virtio common configuration
+structure through the legacy interface. The \field{command_specific_data} is in
+the format \field{struct virtio_admin_cmd_legacy_common_cfg_wr_data} describing
+the access to be performed.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_common_cfg_wr_data {
+ u8 offset; /* Starting byte offset within the common configuration structure to write */
+ u8 reserved[7];
+ u8 data[];
+};
+\end{lstlisting}
+
+The driver sets command \field{opcode} to VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE.
+The driver sets \field{group_member_id} which refers to the member device to be
+accessed. The driver sets \field{offset} which refers to the offset to write within the
+virtio common configuration structure, and excluding the device-specific configuration.
+
+The length of the data to write is simply the length of \field{data}.
+
+No length or alignment restrictions are placed on the value of the
+\field{offset} and the length of the \field{data}, except that the resulting
+access refers to a single field and is completely within the virtio common
+configuration structure, excluding the device-specific configuration.
+
+This command has no command specific result.
+
+\paragraph{Legacy Common Configuration Read Command}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Common Configuration Read Command}
+
+This command has the same effect as reading from the virtio common configuration
+structure through the legacy interface. The \field{command_specific_data} is in
+the format \field{struct virtio_admin_cmd_legacy_common_cfg_rd_data} describing
+the access to be performed.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_common_cfg_rd_data {
+ u8 offset; /* Starting byte offset within the common configuration structure to read */
+};
+\end{lstlisting}
+
+The driver sets command \field{opcode} to VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ.
+
+The driver sets \field{offset} which refers to the offset to read from the
+virtio common configuration structure, and excluding the device-specific
+configuration.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_common_cfg_rd_result {
+ u8 data[];
+};
+\end{lstlisting}
+
+When the command completes successfully, \field{command_specific_result}
+is in the format of \field{struct virtio_admin_cmd_legacy_common_cfg_rd_result}
+returned by the device.
+
+The length of the data read is simply the length of \field{data}.
+
+\paragraph{Legacy Device Configuration Write Command}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Device Configuration Write Command}
+
+This command has the same effect as writing into the virtio device-specific
+configuration through the legacy interface. The \field{command_specific_data} is in
+the format \field{struct virtio_admin_cmd_legacy_dev_reg_wr_data} describing
+the access to be performed.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_dev_reg_wr_data {
+ u8 offset; /* Starting byte offset within the device-specific configuration to write */
+ u8 reserved[7];
+ u8 data[];
+};
+\end{lstlisting}
+
+The driver sets command \field{opcode} to VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE.
+The driver sets \field{group_member_id} which refers to the member device to be
+accessed. The driver sets \field{offset} which refers to the offset to write
+within the virtio device-specific configuration.
+
+The length of the data to write is simply the length of \field{data}.
+
+No length or alignment restrictions are placed on the value of the
+\field{offset} and the length of the \field{data}, except that the resulting
+access refers to a single field and is completely within the device-specific
+configuration.
+
+This command has no command specific result.
+
+\paragraph{Legacy Device Configuration Read Command}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Device Configuration Read Command}
+
+This command has the same effect as reading from the virtio device-specific
+configuration through the legacy interface. The \field{command_specific_data} is in
+the format \field{struct virtio_admin_cmd_legacy_common_cfg_rd_data} describing
+the access to be performed.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_dev_cfg_rd_data {
+ u8 offset; /* Starting byte offset within the device-specific configuration to read */
+};
+\end{lstlisting}
+
+The driver sets command \field{opcode} to VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ.
+The driver sets \field{group_member_id} which refers to the member device to be
+accessed. The driver sets \field{offset} which refers to the offset to read from
+the virtio device-specific configuration.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_dev_reg_rd_result {
+ u8 data[];
+};
+\end{lstlisting}
+
+When the command completes successfully, \field{command_specific_result} is in
+the format of \field{struct virtio_admin_cmd_legacy_dev_reg_rd_result}
+returned by the device.
+
+The length of the data read is simply the length of \field{data}.
+
+\paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Driver Notifications}
+
+If the group owner device or the group member device support driver
+notifications via a memory-mapped operation or I/O operation, these
+notifications are sent to the device via accessing such a notification region
+using a memory or I/O operation instead of sending the notifications through
+the admistration command.
+
+The driver of the owner device can send a driver notification to the member
+device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
+\field{offset} matching \field{Queue Notify} and the \field{data} containing
+the virtqueue index to be notified.
+
+However, as many administration commands are used for slow path configuration,
+a separate fast path mechanism for such notifications is desired. For the
+SR-IOV group type, the optional command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
+addresses this need by returning to the driver one or more addresses which to
+be used to send such driver notifications.
+
+The driver sets command \field{opcode} to VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY.
+The driver sets \field{group_member_id} which refers to the member device to be
+accessed. This command does not use \field{command_specific_data}.
+
+When the command completes successfully, \field{command_specific_result}
+is in the format of \field{struct virtio_admin_cmd_legacy_notify_query_result}.
+
+\begin{lstlisting}
+struct virtio_admin_cmd_legacy_notify_query_entry {
+ u8 data[16];
+};
+
+struct virtio_admin_cmd_legacy_notify_query_result {
+ struct virtio_virtio_admin_cmd_legacy_notify_query_entry entries[];
+};
+\end{lstlisting}
+
+The driver picks the suitable entry when multiple entries are supplied
+by the device.
+
+Refer to the specific transport section for the definition of the
+\field{data}.
+
+This command is currently only defined for the SR-IOV group type.
+
+\devicenormative{\paragraph}{Legacy Interface}{Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface}
+
+A device MUST either support all of, or none of
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ commands.
+
+For VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ commands, the device MUST decode and
+encode (respectively) the value of the \field{data} using the little-endian
+format.
+
+The device MUST fail VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ commands where the value of the
+\field{offset} and the length of the \field{data} does not refer to a
+refer to a single field or is not completely within the virtio common
+configuration structure excluding the device-specific configuration.
+
+The device MUST fail VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ commands where the value of the
+\field{offset} and the length of the \field{data} does not refer to a
+refer to a single field or is not completely within the
+device-specific configuration.
+
+If the device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY it MUST
+also support all of VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ.
+
+The command VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE MUST have the same effect
+as writing into the virtio common configuration structure through the legacy
+interface.
+
+The command VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ MUST have the same effect as
+reading from the virtio common configuration structure through the legacy
+interface.
+
+The command VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE MUST have the same effect as
+writing into the virtio device configuration structure through the legacy
+interface.
+
+The command VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ MUST have the same effect as
+reading from the virtio device configuration structure through the legacy
+interface.
+
+\drivernormative{\paragraph}{Legacy Interface}{Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface}
+
+For VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ commands, the driver MUST encode and
+decod3 (respectively) the value of the \field{data} using the little-endian
+format.
+
+For VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ commands the driver SHOULD set
+\field{offset} and the length of the \field{data} to refer to a
+a single field within the virtio common configuration structure excluding
+the device-specific configuration.
+
+For VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ commands the driver SHOULD set
+\field{offset} and the length of the \field{data} to refer to a
+a single field within the virtio device-specific configuration.
+
+The group member driver SHOULD use the notification region supplied by the group
+owner device to send driver notifications to the device if
+VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY is supported.
diff --git a/admin.tex b/admin.tex
index b0a1a91..e2134e1 100644
--- a/admin.tex
+++ b/admin.tex
@@ -117,7 +117,17 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
\hline
0x0001 & VIRTIO_ADMIN_CMD_LIST_USE & Provides to device list of commands used for this group type \\
\hline
-0x0002 - 0x7FFF & - & Commands using \field{struct virtio_admin_cmd} \\
+0x0002 & VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE & Writes into the legacy common configuration structure \\
+\hline
+0x0003 & VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ & Reads from the legacy common configuration structure \\
+\hline
+0x0004 & VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE & Writes into the legacy device configuration structure \\
+\hline
+0x0005 & VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ & Reads into the legacy device configuration structure \\
+\hline
+0x0006 & VIRTIO_ADMIN_CMD_LEGACY_DEV_NOTIFY_QUERY & Query the notification region \\
+\hline
+0x0007 - 0x7FFF & - & Commands using \field{struct virtio_admin_cmd} \\
\hline
0x8000 - 0xFFFF & - & Reserved for future commands (possibly using a different structure) \\
\hline
@@ -286,6 +296,8 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti
supporting multiple group types, the list of supported commands
might differ between different group types.
+\input{admin-cmds-legacy-interface.tex}
+
\devicenormative{\subsubsection}{Group administration commands}{Basic Facilities of a Virtio Device / Device groups / Group administration commands}
The device MUST validate \field{opcode}, \field{group_type} and
diff --git a/conformance.tex b/conformance.tex
index 01ccd69..dc00e84 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -260,6 +260,8 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\item Section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Legacy Interfaces: A Note on Virtqueue Layout}
\item Section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Legacy Interfaces: A Note on Virtqueue Endianness}
\item Section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Message Framing / Legacy Interface: Message Framing}
+\item Section \ref{devicenormative:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface}
+\item Section \ref{drivernormative:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface}
\item Section \ref{sec:General Initialization And Device Operation / Device Initialization / Legacy Interface: Device Initialization}
\item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Discovery / Legacy Interfaces: A Note on PCI Device Discovery}
\item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Legacy Interfaces: A Note on PCI Device Layout}
--
2.26.2
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply related [flat|nested] 78+ messages in thread
* [virtio-dev] [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 4:17 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 4:17 UTC (permalink / raw)
To: virtio-comment, mst, cohuck, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
This patch links how in a PCI transport a group owner can access group
member (PCI VFs) legacy registers using a legacy registers access
commands using administration virtqueue infrastructure.
Additionally it extend the PCI notification capability through which a
PCI VF device indicates to the driver which PCI BAR region to be used
for driver notifications.
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/167
Signed-off-by: Parav Pandit <parav@nvidia.com>
---
changelog:
v9->v10:
- addressed comments from Cornelia
- fixed errors related to article
- hardwire to hardwires
- replaced various to all
- added hardwire to zero
v7->v8:
- addressed comments from Michael
- made bar offset 64-bit
- prefix legacy specific structure with _legacy
- moved generic normative from pci to generic section
- added link to virtio pci capabilities when referring to bar 0
- remove 'should' from generic description
v6->v7:
- addressed comments from Michael
- removed driver normative about I/O BAR emulation as it does not
make much sense for the spec
- removed references to administration virtqueue
- rewrote driver legacy region access without guest and hypervisor
wording
- added normative for notification region
- added normative for PCI IDs for device which support legacy commands
v5->v6:
- aligned pci capability to 4B as required by PCI spec
- added text for the PCI capability for the group member device
v4->v5:
- split pci transport and generic command section to new patch
- removed multiple references to the VF
- written the description of the command as generic with member
and group device terminology
- reflected many section names to remove VF
v3->v4:
- moved noted to the conformance section details in next patch
- removed queue notify address query AQ command on Michael's suggestion,
though it is fine. Instead replaced with extending virtio_pci_notify_cap
to indicate that legacy queue notifications can be done on the
notification location.
- fixed spelling errors.
- replaced administrative virtqueue to administration virtqueue
- added queue notification capability register to indicate legacy q
notification supported
v2->v3:
- adddressed Jason and Michael's comment to split single register
access command to common config and device specific commands.
- dropped the suggetion to introduce enable/disable command as
admin command cap bit already covers it.
v1->v2:
- addressed comments from Michael
- added theory of operation
- grammar corrections
- removed group fields description from individual commands as
it is already present in generic section
- added endianness normative for legacy device registers region
- renamed the file to drop vf and add legacy prefix
- added overview in commit log
- renamed subsection to reflect command
---
admin-cmds-legacy-interface.tex | 3 ++-
conformance.tex | 1 +
transport-pci-legacy-regs.tex | 42 +++++++++++++++++++++++++++++++++
transport-pci.tex | 2 ++
4 files changed, 47 insertions(+), 1 deletion(-)
create mode 100644 transport-pci-legacy-regs.tex
diff --git a/admin-cmds-legacy-interface.tex b/admin-cmds-legacy-interface.tex
index dd01c0a..e67632b 100644
--- a/admin-cmds-legacy-interface.tex
+++ b/admin-cmds-legacy-interface.tex
@@ -187,7 +187,8 @@ \subsubsection{Legacy Interfaces}\label{sec:Basic Facilities of a Virtio Device
by the device.
Refer to the specific transport section for the definition of the
-\field{data}.
+\field{data}. For the PCI transport refer to section
+\ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}.
This command is currently only defined for the SR-IOV group type.
diff --git a/conformance.tex b/conformance.tex
index dc00e84..b3f2c92 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -267,6 +267,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Legacy Interfaces: A Note on PCI Device Layout}
\item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / Virtio Device Configuration Layout Detection / Legacy Interface: A Note on Device Layout Detection}
\item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / Virtqueue Configuration / Legacy Interface: A Note on Virtqueue Configuration}
+\item Section \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
\item Section \ref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}
\item Section \ref{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Setting the Virtio Revision / Legacy Interfaces: A Note on Setting the Virtio Revision}
\item Section \ref{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Configuring a Virtqueue / Legacy Interface: A Note on Configuring a Virtqueue}
diff --git a/transport-pci-legacy-regs.tex b/transport-pci-legacy-regs.tex
new file mode 100644
index 0000000..ceea28c
--- /dev/null
+++ b/transport-pci-legacy-regs.tex
@@ -0,0 +1,42 @@
+\subsection{Legacy Interface: Group member device Configuration Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
+
+The PCI owner device or the member device or both support driver notifications using
+a notification region defined in \field{struct virtio_pci_legacy_notify_region}.
+
+In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
+\field{region_data} is defined as following:
+
+\begin{lstlisting}
+struct virtio_pci_legacy_notify_region {
+ u8 owner; /* When set to 1, notification region is of the owner device */
+ u8 bar; /* BAR of the member or owner device */
+ u8 padding[6];
+ le64 offset; /* Offset within bar. */
+};
+\end{lstlisting}
+
+The group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
+capability.
+
+The group member device does not use PCI BAR0 in all the Virtio PCI capabilities
+listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
+
+\devicenormative{\subsubsection}{Legacy Interface: Group Member Device Legacy Configuration Region Access}{Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
+
+When a PCI SR-IOV group owner device supports
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group owner device MUST
+hardwire VF BAR0 to zero in the SR-IOV Extended capability and the group memberi
+device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
+
+The group owner device or the group member device or both MAY support driver
+notifications region.
+
+For the SR-IOV group type, the owner device supporting
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
+commands and its member device SHOULD follow the rules for the PCI Device ID,
+Revision ID and Subsystem Device ID of the non-transitional devices documented in
+section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Discovery}.
diff --git a/transport-pci.tex b/transport-pci.tex
index a5c6719..72c78f6 100644
--- a/transport-pci.tex
+++ b/transport-pci.tex
@@ -1212,3 +1212,5 @@ \subsubsection{Driver Handling Interrupts}\label{sec:Virtio Transport Options /
re-examine the configuration space to see what changed.
\end{itemize}
\end{itemize}
+
+\input{transport-pci-legacy-regs.tex}
--
2.26.2
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 78+ messages in thread
* [virtio-comment] [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 4:17 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 4:17 UTC (permalink / raw)
To: virtio-comment, mst, cohuck, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
This patch links how in a PCI transport a group owner can access group
member (PCI VFs) legacy registers using a legacy registers access
commands using administration virtqueue infrastructure.
Additionally it extend the PCI notification capability through which a
PCI VF device indicates to the driver which PCI BAR region to be used
for driver notifications.
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/167
Signed-off-by: Parav Pandit <parav@nvidia.com>
---
changelog:
v9->v10:
- addressed comments from Cornelia
- fixed errors related to article
- hardwire to hardwires
- replaced various to all
- added hardwire to zero
v7->v8:
- addressed comments from Michael
- made bar offset 64-bit
- prefix legacy specific structure with _legacy
- moved generic normative from pci to generic section
- added link to virtio pci capabilities when referring to bar 0
- remove 'should' from generic description
v6->v7:
- addressed comments from Michael
- removed driver normative about I/O BAR emulation as it does not
make much sense for the spec
- removed references to administration virtqueue
- rewrote driver legacy region access without guest and hypervisor
wording
- added normative for notification region
- added normative for PCI IDs for device which support legacy commands
v5->v6:
- aligned pci capability to 4B as required by PCI spec
- added text for the PCI capability for the group member device
v4->v5:
- split pci transport and generic command section to new patch
- removed multiple references to the VF
- written the description of the command as generic with member
and group device terminology
- reflected many section names to remove VF
v3->v4:
- moved noted to the conformance section details in next patch
- removed queue notify address query AQ command on Michael's suggestion,
though it is fine. Instead replaced with extending virtio_pci_notify_cap
to indicate that legacy queue notifications can be done on the
notification location.
- fixed spelling errors.
- replaced administrative virtqueue to administration virtqueue
- added queue notification capability register to indicate legacy q
notification supported
v2->v3:
- adddressed Jason and Michael's comment to split single register
access command to common config and device specific commands.
- dropped the suggetion to introduce enable/disable command as
admin command cap bit already covers it.
v1->v2:
- addressed comments from Michael
- added theory of operation
- grammar corrections
- removed group fields description from individual commands as
it is already present in generic section
- added endianness normative for legacy device registers region
- renamed the file to drop vf and add legacy prefix
- added overview in commit log
- renamed subsection to reflect command
---
admin-cmds-legacy-interface.tex | 3 ++-
conformance.tex | 1 +
transport-pci-legacy-regs.tex | 42 +++++++++++++++++++++++++++++++++
transport-pci.tex | 2 ++
4 files changed, 47 insertions(+), 1 deletion(-)
create mode 100644 transport-pci-legacy-regs.tex
diff --git a/admin-cmds-legacy-interface.tex b/admin-cmds-legacy-interface.tex
index dd01c0a..e67632b 100644
--- a/admin-cmds-legacy-interface.tex
+++ b/admin-cmds-legacy-interface.tex
@@ -187,7 +187,8 @@ \subsubsection{Legacy Interfaces}\label{sec:Basic Facilities of a Virtio Device
by the device.
Refer to the specific transport section for the definition of the
-\field{data}.
+\field{data}. For the PCI transport refer to section
+\ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}.
This command is currently only defined for the SR-IOV group type.
diff --git a/conformance.tex b/conformance.tex
index dc00e84..b3f2c92 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -267,6 +267,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Legacy Interfaces: A Note on PCI Device Layout}
\item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / Virtio Device Configuration Layout Detection / Legacy Interface: A Note on Device Layout Detection}
\item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / Virtqueue Configuration / Legacy Interface: A Note on Virtqueue Configuration}
+\item Section \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
\item Section \ref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}
\item Section \ref{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Setting the Virtio Revision / Legacy Interfaces: A Note on Setting the Virtio Revision}
\item Section \ref{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Configuring a Virtqueue / Legacy Interface: A Note on Configuring a Virtqueue}
diff --git a/transport-pci-legacy-regs.tex b/transport-pci-legacy-regs.tex
new file mode 100644
index 0000000..ceea28c
--- /dev/null
+++ b/transport-pci-legacy-regs.tex
@@ -0,0 +1,42 @@
+\subsection{Legacy Interface: Group member device Configuration Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
+
+The PCI owner device or the member device or both support driver notifications using
+a notification region defined in \field{struct virtio_pci_legacy_notify_region}.
+
+In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
+\field{region_data} is defined as following:
+
+\begin{lstlisting}
+struct virtio_pci_legacy_notify_region {
+ u8 owner; /* When set to 1, notification region is of the owner device */
+ u8 bar; /* BAR of the member or owner device */
+ u8 padding[6];
+ le64 offset; /* Offset within bar. */
+};
+\end{lstlisting}
+
+The group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
+capability.
+
+The group member device does not use PCI BAR0 in all the Virtio PCI capabilities
+listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
+
+\devicenormative{\subsubsection}{Legacy Interface: Group Member Device Legacy Configuration Region Access}{Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
+
+When a PCI SR-IOV group owner device supports
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group owner device MUST
+hardwire VF BAR0 to zero in the SR-IOV Extended capability and the group memberi
+device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
+
+The group owner device or the group member device or both MAY support driver
+notifications region.
+
+For the SR-IOV group type, the owner device supporting
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
+VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
+commands and its member device SHOULD follow the rules for the PCI Device ID,
+Revision ID and Subsystem Device ID of the non-transitional devices documented in
+section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Discovery}.
diff --git a/transport-pci.tex b/transport-pci.tex
index a5c6719..72c78f6 100644
--- a/transport-pci.tex
+++ b/transport-pci.tex
@@ -1212,3 +1212,5 @@ \subsubsection{Driver Handling Interrupts}\label{sec:Virtio Transport Options /
re-examine the configuration space to see what changed.
\end{itemize}
\end{itemize}
+
+\input{transport-pci-legacy-regs.tex}
--
2.26.2
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply related [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 2/4] admin: Fix section numbering
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 13:39 ` Cornelia Huck
-1 siblings, 0 replies; 78+ messages in thread
From: Cornelia Huck @ 2023-07-06 13:39 UTC (permalink / raw)
To: Parav Pandit, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
> Requirements are put one additional level down. Fix it.
>
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
> changelog:
> v9->v10:
> - addressed comments from Cornelia
> - fixed requirements for administration virtqueue section
> v4->v5:
> - new patch
> ---
> admin.tex | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 2/4] admin: Fix section numbering
@ 2023-07-06 13:39 ` Cornelia Huck
0 siblings, 0 replies; 78+ messages in thread
From: Cornelia Huck @ 2023-07-06 13:39 UTC (permalink / raw)
To: Parav Pandit, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
> Requirements are put one additional level down. Fix it.
>
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
> changelog:
> v9->v10:
> - addressed comments from Cornelia
> - fixed requirements for administration virtqueue section
> v4->v5:
> - new patch
> ---
> admin.tex | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 3/4] admin: Add group member legacy register access commands
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 16:12 ` Cornelia Huck
-1 siblings, 0 replies; 78+ messages in thread
From: Cornelia Huck @ 2023-07-06 16:12 UTC (permalink / raw)
To: Parav Pandit, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
> diff --git a/admin-cmds-legacy-interface.tex b/admin-cmds-legacy-interface.tex
> new file mode 100644
> index 0000000..dd01c0a
> --- /dev/null
> +++ b/admin-cmds-legacy-interface.tex
> @@ -0,0 +1,261 @@
> +\subsubsection{Legacy Interfaces}\label{sec:Basic Facilities of a Virtio Device / Device groups / Group
> +administration commands / Legacy Interface}
> +
> +In some systems, there is a need to support utilizing the legacy driver with
> +the device that do not directly support the legacy interface. In such scenarios,
Please use either Michael's or my suggestion from v9 here, using
definite articles here isn't a good idea.
> +a group owner device can provide the legacy interface functionality for the
> +group member devices. The driver of an owner device can then access the legacy
> +interface of a member device on behalf of the legacy member device driver.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 3/4] admin: Add group member legacy register access commands
@ 2023-07-06 16:12 ` Cornelia Huck
0 siblings, 0 replies; 78+ messages in thread
From: Cornelia Huck @ 2023-07-06 16:12 UTC (permalink / raw)
To: Parav Pandit, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
> diff --git a/admin-cmds-legacy-interface.tex b/admin-cmds-legacy-interface.tex
> new file mode 100644
> index 0000000..dd01c0a
> --- /dev/null
> +++ b/admin-cmds-legacy-interface.tex
> @@ -0,0 +1,261 @@
> +\subsubsection{Legacy Interfaces}\label{sec:Basic Facilities of a Virtio Device / Device groups / Group
> +administration commands / Legacy Interface}
> +
> +In some systems, there is a need to support utilizing the legacy driver with
> +the device that do not directly support the legacy interface. In such scenarios,
Please use either Michael's or my suggestion from v9 here, using
definite articles here isn't a good idea.
> +a group owner device can provide the legacy interface functionality for the
> +group member devices. The driver of an owner device can then access the legacy
> +interface of a member device on behalf of the legacy member device driver.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 3/4] admin: Add group member legacy register access commands
2023-07-06 16:12 ` [virtio-comment] " Cornelia Huck
@ 2023-07-06 16:16 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:16 UTC (permalink / raw)
To: Cornelia Huck, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Thursday, July 6, 2023 12:12 PM
> > +In some systems, there is a need to support utilizing the legacy
> > +driver with the device that do not directly support the legacy
> > +interface. In such scenarios,
>
> Please use either Michael's or my suggestion from v9 here, using definite
> articles here isn't a good idea.
Yes, working on it.
I am taking, below suggested version.
In some systems, there is a need to support utilizing a legacy driver with
a device that does not directly support the legacy interface.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 3/4] admin: Add group member legacy register access commands
@ 2023-07-06 16:16 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:16 UTC (permalink / raw)
To: Cornelia Huck, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Thursday, July 6, 2023 12:12 PM
> > +In some systems, there is a need to support utilizing the legacy
> > +driver with the device that do not directly support the legacy
> > +interface. In such scenarios,
>
> Please use either Michael's or my suggestion from v9 here, using definite
> articles here isn't a good idea.
Yes, working on it.
I am taking, below suggested version.
In some systems, there is a need to support utilizing a legacy driver with
a device that does not directly support the legacy interface.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 16:28 ` Cornelia Huck
-1 siblings, 0 replies; 78+ messages in thread
From: Cornelia Huck @ 2023-07-06 16:28 UTC (permalink / raw)
To: Parav Pandit, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
> diff --git a/transport-pci-legacy-regs.tex b/transport-pci-legacy-regs.tex
> new file mode 100644
> index 0000000..ceea28c
> --- /dev/null
> +++ b/transport-pci-legacy-regs.tex
> @@ -0,0 +1,42 @@
> +\subsection{Legacy Interface: Group member device Configuration Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> +
> +The PCI owner device or the member device or both support driver notifications using
What about
"The PCI owner device, the member device, or both can choose to
support..." ?
> +a notification region defined in \field{struct virtio_pci_legacy_notify_region}.
> +
> +In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
> +\field{region_data} is defined as following:
> +
> +\begin{lstlisting}
> +struct virtio_pci_legacy_notify_region {
> + u8 owner; /* When set to 1, notification region is of the owner device */
> + u8 bar; /* BAR of the member or owner device */
> + u8 padding[6];
> + le64 offset; /* Offset within bar. */
> +};
> +\end{lstlisting}
> +
> +The group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
> +capability.
> +
> +The group member device does not use PCI BAR0 in all the Virtio PCI capabilities
"in [or for?] any of the...", I guess?
> +listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
> +
> +\devicenormative{\subsubsection}{Legacy Interface: Group Member Device Legacy Configuration Region Access}{Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> +
> +When a PCI SR-IOV group owner device supports
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group owner device MUST
> +hardwire VF BAR0 to zero in the SR-IOV Extended capability and the group memberi
s/memberi/member/
> +device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
> +
> +The group owner device or the group member device or both MAY support driver
> +notifications region.
Make this "a driver notification region"?
> +
> +For the SR-IOV group type, the owner device supporting
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> +commands and its member device SHOULD follow the rules for the PCI Device ID,
> +Revision ID and Subsystem Device ID of the non-transitional devices documented in
> +section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Discovery}.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 16:28 ` Cornelia Huck
0 siblings, 0 replies; 78+ messages in thread
From: Cornelia Huck @ 2023-07-06 16:28 UTC (permalink / raw)
To: Parav Pandit, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, yishaih, maorg, shahafs, Parav Pandit
On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
> diff --git a/transport-pci-legacy-regs.tex b/transport-pci-legacy-regs.tex
> new file mode 100644
> index 0000000..ceea28c
> --- /dev/null
> +++ b/transport-pci-legacy-regs.tex
> @@ -0,0 +1,42 @@
> +\subsection{Legacy Interface: Group member device Configuration Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> +
> +The PCI owner device or the member device or both support driver notifications using
What about
"The PCI owner device, the member device, or both can choose to
support..." ?
> +a notification region defined in \field{struct virtio_pci_legacy_notify_region}.
> +
> +In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
> +\field{region_data} is defined as following:
> +
> +\begin{lstlisting}
> +struct virtio_pci_legacy_notify_region {
> + u8 owner; /* When set to 1, notification region is of the owner device */
> + u8 bar; /* BAR of the member or owner device */
> + u8 padding[6];
> + le64 offset; /* Offset within bar. */
> +};
> +\end{lstlisting}
> +
> +The group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
> +capability.
> +
> +The group member device does not use PCI BAR0 in all the Virtio PCI capabilities
"in [or for?] any of the...", I guess?
> +listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
> +
> +\devicenormative{\subsubsection}{Legacy Interface: Group Member Device Legacy Configuration Region Access}{Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> +
> +When a PCI SR-IOV group owner device supports
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group owner device MUST
> +hardwire VF BAR0 to zero in the SR-IOV Extended capability and the group memberi
s/memberi/member/
> +device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
> +
> +The group owner device or the group member device or both MAY support driver
> +notifications region.
Make this "a driver notification region"?
> +
> +For the SR-IOV group type, the owner device supporting
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> +commands and its member device SHOULD follow the rules for the PCI Device ID,
> +Revision ID and Subsystem Device ID of the non-transitional devices documented in
> +section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Discovery}.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 16:28 ` [virtio-comment] " Cornelia Huck
@ 2023-07-06 16:33 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:33 UTC (permalink / raw)
To: Cornelia Huck, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Thursday, July 6, 2023 12:28 PM
>
> On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>
> > diff --git a/transport-pci-legacy-regs.tex
> > b/transport-pci-legacy-regs.tex new file mode 100644 index
> > 0000000..ceea28c
> > --- /dev/null
> > +++ b/transport-pci-legacy-regs.tex
> > @@ -0,0 +1,42 @@
> > +\subsection{Legacy Interface: Group member device Configuration
> > +Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI
> > +Bus / Legacy Interface: Group Member Device Configuration Region
> > +Access}
> > +
> > +The PCI owner device or the member device or both support driver
> > +notifications using
>
> What about
>
> "The PCI owner device, the member device, or both can choose to support..." ?
>
Fine too.
Any thing wrong in having or as above, so I don't write it next time?
Or that in current form reads better to me.
> > +a notification region defined in \field{struct
> virtio_pci_legacy_notify_region}.
> > +
> > +In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
> > +\field{region_data} is defined as following:
> > +
> > +\begin{lstlisting}
> > +struct virtio_pci_legacy_notify_region {
> > + u8 owner; /* When set to 1, notification region is of the owner device
> */
> > + u8 bar; /* BAR of the member or owner device */
> > + u8 padding[6];
> > + le64 offset; /* Offset within bar. */ }; \end{lstlisting}
> > +
> > +The group owner device hardwires VF BAR0 to zero in the SR-IOV
> > +Extended capability.
> > +
> > +The group member device does not use PCI BAR0 in all the Virtio PCI
> > +capabilities
>
> "in [or for?] any of the...", I guess?
Will change to "Any of the ".
>
> > +listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus /
> Virtio Structure PCI Capabilities}.
> > +
> > +\devicenormative{\subsubsection}{Legacy Interface: Group Member
> > +Device Legacy Configuration Region Access}{Virtio Transport Options /
> > +Virtio Over PCI Bus / Legacy Interface: Group Member Device
> > +Configuration Region Access}
> > +
> > +When a PCI SR-IOV group owner device supports
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
> > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group
> owner
> > +device MUST hardwire VF BAR0 to zero in the SR-IOV Extended
> > +capability and the group memberi
>
> s/memberi/member/
>
Yes, already changed in my v11 where patch 3 and 4 content is merged to single generic section.
> > +device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
> > +
> > +The group owner device or the group member device or both MAY support
> > +driver notifications region.
>
> Make this "a driver notification region"?
>
Notifications are generally more than one and spec has the section "driver notifications", so...
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 16:33 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:33 UTC (permalink / raw)
To: Cornelia Huck, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Thursday, July 6, 2023 12:28 PM
>
> On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>
> > diff --git a/transport-pci-legacy-regs.tex
> > b/transport-pci-legacy-regs.tex new file mode 100644 index
> > 0000000..ceea28c
> > --- /dev/null
> > +++ b/transport-pci-legacy-regs.tex
> > @@ -0,0 +1,42 @@
> > +\subsection{Legacy Interface: Group member device Configuration
> > +Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI
> > +Bus / Legacy Interface: Group Member Device Configuration Region
> > +Access}
> > +
> > +The PCI owner device or the member device or both support driver
> > +notifications using
>
> What about
>
> "The PCI owner device, the member device, or both can choose to support..." ?
>
Fine too.
Any thing wrong in having or as above, so I don't write it next time?
Or that in current form reads better to me.
> > +a notification region defined in \field{struct
> virtio_pci_legacy_notify_region}.
> > +
> > +In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
> > +\field{region_data} is defined as following:
> > +
> > +\begin{lstlisting}
> > +struct virtio_pci_legacy_notify_region {
> > + u8 owner; /* When set to 1, notification region is of the owner device
> */
> > + u8 bar; /* BAR of the member or owner device */
> > + u8 padding[6];
> > + le64 offset; /* Offset within bar. */ }; \end{lstlisting}
> > +
> > +The group owner device hardwires VF BAR0 to zero in the SR-IOV
> > +Extended capability.
> > +
> > +The group member device does not use PCI BAR0 in all the Virtio PCI
> > +capabilities
>
> "in [or for?] any of the...", I guess?
Will change to "Any of the ".
>
> > +listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus /
> Virtio Structure PCI Capabilities}.
> > +
> > +\devicenormative{\subsubsection}{Legacy Interface: Group Member
> > +Device Legacy Configuration Region Access}{Virtio Transport Options /
> > +Virtio Over PCI Bus / Legacy Interface: Group Member Device
> > +Configuration Region Access}
> > +
> > +When a PCI SR-IOV group owner device supports
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
> > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group
> owner
> > +device MUST hardwire VF BAR0 to zero in the SR-IOV Extended
> > +capability and the group memberi
>
> s/memberi/member/
>
Yes, already changed in my v11 where patch 3 and 4 content is merged to single generic section.
> > +device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
> > +
> > +The group owner device or the group member device or both MAY support
> > +driver notifications region.
>
> Make this "a driver notification region"?
>
Notifications are generally more than one and spec has the section "driver notifications", so...
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 16:28 ` [virtio-comment] " Cornelia Huck
@ 2023-07-06 16:39 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 16:39 UTC (permalink / raw)
To: Cornelia Huck
Cc: Parav Pandit, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, yishaih, maorg, shahafs
On Thu, Jul 06, 2023 at 06:28:21PM +0200, Cornelia Huck wrote:
> On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>
> > diff --git a/transport-pci-legacy-regs.tex b/transport-pci-legacy-regs.tex
> > new file mode 100644
> > index 0000000..ceea28c
> > --- /dev/null
> > +++ b/transport-pci-legacy-regs.tex
> > @@ -0,0 +1,42 @@
> > +\subsection{Legacy Interface: Group member device Configuration Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> > +
> > +The PCI owner device or the member device or both support driver notifications using
>
> What about
>
> "The PCI owner device, the member device, or both can choose to
> support..." ?
>
> > +a notification region defined in \field{struct virtio_pci_legacy_notify_region}.
> > +
> > +In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
> > +\field{region_data} is defined as following:
> > +
> > +\begin{lstlisting}
> > +struct virtio_pci_legacy_notify_region {
> > + u8 owner; /* When set to 1, notification region is of the owner device */
> > + u8 bar; /* BAR of the member or owner device */
> > + u8 padding[6];
> > + le64 offset; /* Offset within bar. */
> > +};
> > +\end{lstlisting}
> > +
> > +The group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
> > +capability.
> > +
> > +The group member device does not use PCI BAR0 in all the Virtio PCI capabilities
>
> "in [or for?] any of the...", I guess?
>
> > +listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
> > +
> > +\devicenormative{\subsubsection}{Legacy Interface: Group Member Device Legacy Configuration Region Access}{Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> > +
> > +When a PCI SR-IOV group owner device supports
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group owner device MUST
> > +hardwire VF BAR0 to zero in the SR-IOV Extended capability and the group memberi
>
> s/memberi/member/
>
> > +device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
> > +
> > +The group owner device or the group member device or both MAY support driver
> > +notifications region.
>
> Make this "a driver notification region"?
I think in fact for conformance we can just refer to supporting the command.
The command can return an array of structures, each referring to
the memory of the owner device or the member device.
> > +
> > +For the SR-IOV group type, the owner device supporting
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> > +commands and its member device SHOULD follow the rules for the PCI Device ID,
what does "its" mean here? Of the group?
Members of the SR-IOV group type are VFs. They can not follow
the rules for the Device ID: the spec says:
This field in all VFs returns FFFFh when read.
Even if you somehow refer to the software it's extraneous anyway
since the spec proceeds: VI software should return the Vendor ID value
from the associated PF as the Vendor ID value for the VF.
We'll need a separate statement for Device ID.
> > +Revision ID and Subsystem Device ID of the non-transitional devices documented in
> > +section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Discovery}.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 16:39 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 16:39 UTC (permalink / raw)
To: Cornelia Huck
Cc: Parav Pandit, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, yishaih, maorg, shahafs
On Thu, Jul 06, 2023 at 06:28:21PM +0200, Cornelia Huck wrote:
> On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>
> > diff --git a/transport-pci-legacy-regs.tex b/transport-pci-legacy-regs.tex
> > new file mode 100644
> > index 0000000..ceea28c
> > --- /dev/null
> > +++ b/transport-pci-legacy-regs.tex
> > @@ -0,0 +1,42 @@
> > +\subsection{Legacy Interface: Group member device Configuration Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> > +
> > +The PCI owner device or the member device or both support driver notifications using
>
> What about
>
> "The PCI owner device, the member device, or both can choose to
> support..." ?
>
> > +a notification region defined in \field{struct virtio_pci_legacy_notify_region}.
> > +
> > +In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
> > +\field{region_data} is defined as following:
> > +
> > +\begin{lstlisting}
> > +struct virtio_pci_legacy_notify_region {
> > + u8 owner; /* When set to 1, notification region is of the owner device */
> > + u8 bar; /* BAR of the member or owner device */
> > + u8 padding[6];
> > + le64 offset; /* Offset within bar. */
> > +};
> > +\end{lstlisting}
> > +
> > +The group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
> > +capability.
> > +
> > +The group member device does not use PCI BAR0 in all the Virtio PCI capabilities
>
> "in [or for?] any of the...", I guess?
>
> > +listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
> > +
> > +\devicenormative{\subsubsection}{Legacy Interface: Group Member Device Legacy Configuration Region Access}{Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> > +
> > +When a PCI SR-IOV group owner device supports
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group owner device MUST
> > +hardwire VF BAR0 to zero in the SR-IOV Extended capability and the group memberi
>
> s/memberi/member/
>
> > +device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
> > +
> > +The group owner device or the group member device or both MAY support driver
> > +notifications region.
>
> Make this "a driver notification region"?
I think in fact for conformance we can just refer to supporting the command.
The command can return an array of structures, each referring to
the memory of the owner device or the member device.
> > +
> > +For the SR-IOV group type, the owner device supporting
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> > +commands and its member device SHOULD follow the rules for the PCI Device ID,
what does "its" mean here? Of the group?
Members of the SR-IOV group type are VFs. They can not follow
the rules for the Device ID: the spec says:
This field in all VFs returns FFFFh when read.
Even if you somehow refer to the software it's extraneous anyway
since the spec proceeds: VI software should return the Vendor ID value
from the associated PF as the Vendor ID value for the VF.
We'll need a separate statement for Device ID.
> > +Revision ID and Subsystem Device ID of the non-transitional devices documented in
> > +section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Discovery}.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 16:33 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 16:42 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 16:42 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 04:33:01PM +0000, Parav Pandit wrote:
>
>
> > From: Cornelia Huck <cohuck@redhat.com>
> > Sent: Thursday, July 6, 2023 12:28 PM
> >
> > On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
> >
> > > diff --git a/transport-pci-legacy-regs.tex
> > > b/transport-pci-legacy-regs.tex new file mode 100644 index
> > > 0000000..ceea28c
> > > --- /dev/null
> > > +++ b/transport-pci-legacy-regs.tex
> > > @@ -0,0 +1,42 @@
> > > +\subsection{Legacy Interface: Group member device Configuration
> > > +Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI
> > > +Bus / Legacy Interface: Group Member Device Configuration Region
> > > +Access}
> > > +
> > > +The PCI owner device or the member device or both support driver
> > > +notifications using
> >
> > What about
> >
> > "The PCI owner device, the member device, or both can choose to support..." ?
> >
> Fine too.
> Any thing wrong in having or as above, so I don't write it next time?
> Or that in current form reads better to me.
>
> > > +a notification region defined in \field{struct
> > virtio_pci_legacy_notify_region}.
> > > +
> > > +In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
> > > +\field{region_data} is defined as following:
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_pci_legacy_notify_region {
> > > + u8 owner; /* When set to 1, notification region is of the owner device
> > */
> > > + u8 bar; /* BAR of the member or owner device */
> > > + u8 padding[6];
> > > + le64 offset; /* Offset within bar. */ }; \end{lstlisting}
> > > +
> > > +The group owner device hardwires VF BAR0 to zero in the SR-IOV
> > > +Extended capability.
> > > +
> > > +The group member device does not use PCI BAR0 in all the Virtio PCI
> > > +capabilities
> >
> > "in [or for?] any of the...", I guess?
> Will change to "Any of the ".
>
> >
> > > +listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus /
> > Virtio Structure PCI Capabilities}.
> > > +
> > > +\devicenormative{\subsubsection}{Legacy Interface: Group Member
> > > +Device Legacy Configuration Region Access}{Virtio Transport Options /
> > > +Virtio Over PCI Bus / Legacy Interface: Group Member Device
> > > +Configuration Region Access}
> > > +
> > > +When a PCI SR-IOV group owner device supports
> > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
> > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group
> > owner
> > > +device MUST hardwire VF BAR0 to zero in the SR-IOV Extended
> > > +capability and the group memberi
> >
> > s/memberi/member/
> >
> Yes, already changed in my v11 where patch 3 and 4 content is merged to single generic section.
>
>
> > > +device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
> > > +
> > > +The group owner device or the group member device or both MAY support
> > > +driver notifications region.
> >
> > Make this "a driver notification region"?
> >
> Notifications are generally more than one and spec has the section "driver notifications", so...
>
We will need to detail how notifications work though. The reason
is that the legacy notifications are received by owner driver
(which is not legacy!) and forwarded to device.
We need to explain exactly how this is done for people who
don't read minds and did not follow 3 months of mailing list
debates, and explain how this has the same effect as
triggering driver notification through the legacy
interface.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 16:42 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 16:42 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 04:33:01PM +0000, Parav Pandit wrote:
>
>
> > From: Cornelia Huck <cohuck@redhat.com>
> > Sent: Thursday, July 6, 2023 12:28 PM
> >
> > On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
> >
> > > diff --git a/transport-pci-legacy-regs.tex
> > > b/transport-pci-legacy-regs.tex new file mode 100644 index
> > > 0000000..ceea28c
> > > --- /dev/null
> > > +++ b/transport-pci-legacy-regs.tex
> > > @@ -0,0 +1,42 @@
> > > +\subsection{Legacy Interface: Group member device Configuration
> > > +Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI
> > > +Bus / Legacy Interface: Group Member Device Configuration Region
> > > +Access}
> > > +
> > > +The PCI owner device or the member device or both support driver
> > > +notifications using
> >
> > What about
> >
> > "The PCI owner device, the member device, or both can choose to support..." ?
> >
> Fine too.
> Any thing wrong in having or as above, so I don't write it next time?
> Or that in current form reads better to me.
>
> > > +a notification region defined in \field{struct
> > virtio_pci_legacy_notify_region}.
> > > +
> > > +In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
> > > +\field{region_data} is defined as following:
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_pci_legacy_notify_region {
> > > + u8 owner; /* When set to 1, notification region is of the owner device
> > */
> > > + u8 bar; /* BAR of the member or owner device */
> > > + u8 padding[6];
> > > + le64 offset; /* Offset within bar. */ }; \end{lstlisting}
> > > +
> > > +The group owner device hardwires VF BAR0 to zero in the SR-IOV
> > > +Extended capability.
> > > +
> > > +The group member device does not use PCI BAR0 in all the Virtio PCI
> > > +capabilities
> >
> > "in [or for?] any of the...", I guess?
> Will change to "Any of the ".
>
> >
> > > +listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus /
> > Virtio Structure PCI Capabilities}.
> > > +
> > > +\devicenormative{\subsubsection}{Legacy Interface: Group Member
> > > +Device Legacy Configuration Region Access}{Virtio Transport Options /
> > > +Virtio Over PCI Bus / Legacy Interface: Group Member Device
> > > +Configuration Region Access}
> > > +
> > > +When a PCI SR-IOV group owner device supports
> > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
> > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group
> > owner
> > > +device MUST hardwire VF BAR0 to zero in the SR-IOV Extended
> > > +capability and the group memberi
> >
> > s/memberi/member/
> >
> Yes, already changed in my v11 where patch 3 and 4 content is merged to single generic section.
>
>
> > > +device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
> > > +
> > > +The group owner device or the group member device or both MAY support
> > > +driver notifications region.
> >
> > Make this "a driver notification region"?
> >
> Notifications are generally more than one and spec has the section "driver notifications", so...
>
We will need to detail how notifications work though. The reason
is that the legacy notifications are received by owner driver
(which is not legacy!) and forwarded to device.
We need to explain exactly how this is done for people who
don't read minds and did not follow 3 months of mailing list
debates, and explain how this has the same effect as
triggering driver notification through the legacy
interface.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 16:39 ` [virtio-comment] " Michael S. Tsirkin
@ 2023-07-06 16:45 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:45 UTC (permalink / raw)
To: Michael S. Tsirkin, Cornelia Huck
Cc: virtio-comment, david.edmondson, virtio-dev, sburla, jasowang,
Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 12:39 PM
> > > +The group owner device or the group member device or both MAY
> > > +support driver notifications region.
> >
> > Make this "a driver notification region"?
>
> I think in fact for conformance we can just refer to supporting the command.
> The command can return an array of structures, each referring to the memory
> of the owner device or the member device.
>
Array and referring to owner/member is already present in this patch.
Do you suggest to drop above statement?
>
> > > +
> > > +For the SR-IOV group type, the owner device supporting
> > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
> > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
> > > +VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> > > +commands and its member device SHOULD follow the rules for the PCI
> > > +Device ID,
>
> what does "its" mean here? Of the group?
Yes, will change to the member device of the group.
> Members of the SR-IOV group type are VFs. They can not follow the rules for
> the Device ID: the spec says:
> This field in all VFs returns FFFFh when read.
>
> Even if you somehow refer to the software it's extraneous anyway since the
> spec proceeds: VI software should return the Vendor ID value from the
> associated PF as the Vendor ID value for the VF.
>
> We'll need a separate statement for Device ID.
>
Will split the line for Device ID.
> > > +Revision ID and Subsystem Device ID of the non-transitional devices
> > > +documented in section \ref{sec:Virtio Transport Options / Virtio Over PCI
> Bus / PCI Device Discovery}.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 16:45 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:45 UTC (permalink / raw)
To: Michael S. Tsirkin, Cornelia Huck
Cc: virtio-comment, david.edmondson, virtio-dev, sburla, jasowang,
Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 12:39 PM
> > > +The group owner device or the group member device or both MAY
> > > +support driver notifications region.
> >
> > Make this "a driver notification region"?
>
> I think in fact for conformance we can just refer to supporting the command.
> The command can return an array of structures, each referring to the memory
> of the owner device or the member device.
>
Array and referring to owner/member is already present in this patch.
Do you suggest to drop above statement?
>
> > > +
> > > +For the SR-IOV group type, the owner device supporting
> > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
> > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
> > > +VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> > > +commands and its member device SHOULD follow the rules for the PCI
> > > +Device ID,
>
> what does "its" mean here? Of the group?
Yes, will change to the member device of the group.
> Members of the SR-IOV group type are VFs. They can not follow the rules for
> the Device ID: the spec says:
> This field in all VFs returns FFFFh when read.
>
> Even if you somehow refer to the software it's extraneous anyway since the
> spec proceeds: VI software should return the Vendor ID value from the
> associated PF as the Vendor ID value for the VF.
>
> We'll need a separate statement for Device ID.
>
Will split the line for Device ID.
> > > +Revision ID and Subsystem Device ID of the non-transitional devices
> > > +documented in section \ref{sec:Virtio Transport Options / Virtio Over PCI
> Bus / PCI Device Discovery}.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 16:33 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 16:47 ` Cornelia Huck
-1 siblings, 0 replies; 78+ messages in thread
From: Cornelia Huck @ 2023-07-06 16:47 UTC (permalink / raw)
To: Parav Pandit, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>> From: Cornelia Huck <cohuck@redhat.com>
>> Sent: Thursday, July 6, 2023 12:28 PM
>>
>> On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>>
>> > diff --git a/transport-pci-legacy-regs.tex
>> > b/transport-pci-legacy-regs.tex new file mode 100644 index
>> > 0000000..ceea28c
>> > --- /dev/null
>> > +++ b/transport-pci-legacy-regs.tex
>> > @@ -0,0 +1,42 @@
>> > +\subsection{Legacy Interface: Group member device Configuration
>> > +Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI
>> > +Bus / Legacy Interface: Group Member Device Configuration Region
>> > +Access}
>> > +
>> > +The PCI owner device or the member device or both support driver
>> > +notifications using
>>
>> What about
>>
>> "The PCI owner device, the member device, or both can choose to support..." ?
>>
> Fine too.
> Any thing wrong in having or as above, so I don't write it next time?
> Or that in current form reads better to me.
Just a bare "support" does not really tell the reader if this is
something that is required or optional. Dropping the first "or" makes it
read better for me.
>
>> > +a notification region defined in \field{struct
>> virtio_pci_legacy_notify_region}.
(...)
>> > +The group owner device or the group member device or both MAY support
>> > +driver notifications region.
>>
>> Make this "a driver notification region"?
>>
> Notifications are generally more than one and spec has the section "driver notifications", so...
I'd parse this as "a region for the purpose of notification" (and
"notification region" is used above)... but in any case, we need the
article here, I think.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 16:47 ` Cornelia Huck
0 siblings, 0 replies; 78+ messages in thread
From: Cornelia Huck @ 2023-07-06 16:47 UTC (permalink / raw)
To: Parav Pandit, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>> From: Cornelia Huck <cohuck@redhat.com>
>> Sent: Thursday, July 6, 2023 12:28 PM
>>
>> On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>>
>> > diff --git a/transport-pci-legacy-regs.tex
>> > b/transport-pci-legacy-regs.tex new file mode 100644 index
>> > 0000000..ceea28c
>> > --- /dev/null
>> > +++ b/transport-pci-legacy-regs.tex
>> > @@ -0,0 +1,42 @@
>> > +\subsection{Legacy Interface: Group member device Configuration
>> > +Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI
>> > +Bus / Legacy Interface: Group Member Device Configuration Region
>> > +Access}
>> > +
>> > +The PCI owner device or the member device or both support driver
>> > +notifications using
>>
>> What about
>>
>> "The PCI owner device, the member device, or both can choose to support..." ?
>>
> Fine too.
> Any thing wrong in having or as above, so I don't write it next time?
> Or that in current form reads better to me.
Just a bare "support" does not really tell the reader if this is
something that is required or optional. Dropping the first "or" makes it
read better for me.
>
>> > +a notification region defined in \field{struct
>> virtio_pci_legacy_notify_region}.
(...)
>> > +The group owner device or the group member device or both MAY support
>> > +driver notifications region.
>>
>> Make this "a driver notification region"?
>>
> Notifications are generally more than one and spec has the section "driver notifications", so...
I'd parse this as "a region for the purpose of notification" (and
"notification region" is used above)... but in any case, we need the
article here, I think.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 16:45 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 16:50 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 16:50 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 04:45:50PM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 12:39 PM
>
> > > > +The group owner device or the group member device or both MAY
> > > > +support driver notifications region.
> > >
> > > Make this "a driver notification region"?
> >
> > I think in fact for conformance we can just refer to supporting the command.
> > The command can return an array of structures, each referring to the memory
> > of the owner device or the member device.
> >
> Array and referring to owner/member is already present in this patch.
I don't see a statement that devices MAY support VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
with entries returning just owner, just member, or both.
> Do you suggest to drop above statement?
> >
> > > > +
> > > > +For the SR-IOV group type, the owner device supporting
> > > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
> > > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
> > > > +VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> > > > +commands and its member device SHOULD follow the rules for the PCI
> > > > +Device ID,
> >
> > what does "its" mean here? Of the group?
> Yes, will change to the member device of the group.
>
> > Members of the SR-IOV group type are VFs. They can not follow the rules for
> > the Device ID: the spec says:
> > This field in all VFs returns FFFFh when read.
> >
> > Even if you somehow refer to the software it's extraneous anyway since the
> > spec proceeds: VI software should return the Vendor ID value from the
> > associated PF as the Vendor ID value for the VF.
> >
> > We'll need a separate statement for Device ID.
> >
> Will split the line for Device ID.
>
> > > > +Revision ID and Subsystem Device ID of the non-transitional devices
> > > > +documented in section \ref{sec:Virtio Transport Options / Virtio Over PCI
> > Bus / PCI Device Discovery}.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 16:50 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 16:50 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 04:45:50PM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 12:39 PM
>
> > > > +The group owner device or the group member device or both MAY
> > > > +support driver notifications region.
> > >
> > > Make this "a driver notification region"?
> >
> > I think in fact for conformance we can just refer to supporting the command.
> > The command can return an array of structures, each referring to the memory
> > of the owner device or the member device.
> >
> Array and referring to owner/member is already present in this patch.
I don't see a statement that devices MAY support VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
with entries returning just owner, just member, or both.
> Do you suggest to drop above statement?
> >
> > > > +
> > > > +For the SR-IOV group type, the owner device supporting
> > > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
> > > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
> > > > +VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> > > > +commands and its member device SHOULD follow the rules for the PCI
> > > > +Device ID,
> >
> > what does "its" mean here? Of the group?
> Yes, will change to the member device of the group.
>
> > Members of the SR-IOV group type are VFs. They can not follow the rules for
> > the Device ID: the spec says:
> > This field in all VFs returns FFFFh when read.
> >
> > Even if you somehow refer to the software it's extraneous anyway since the
> > spec proceeds: VI software should return the Vendor ID value from the
> > associated PF as the Vendor ID value for the VF.
> >
> > We'll need a separate statement for Device ID.
> >
> Will split the line for Device ID.
>
> > > > +Revision ID and Subsystem Device ID of the non-transitional devices
> > > > +documented in section \ref{sec:Virtio Transport Options / Virtio Over PCI
> > Bus / PCI Device Discovery}.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 16:47 ` [virtio-comment] " Cornelia Huck
@ 2023-07-06 16:52 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:52 UTC (permalink / raw)
To: Cornelia Huck, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Thursday, July 6, 2023 12:47 PM
>
> On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>
> >> From: Cornelia Huck <cohuck@redhat.com>
> >> Sent: Thursday, July 6, 2023 12:28 PM
> >>
> >> On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
> >>
> >> > diff --git a/transport-pci-legacy-regs.tex
> >> > b/transport-pci-legacy-regs.tex new file mode 100644 index
> >> > 0000000..ceea28c
> >> > --- /dev/null
> >> > +++ b/transport-pci-legacy-regs.tex
> >> > @@ -0,0 +1,42 @@
> >> > +\subsection{Legacy Interface: Group member device Configuration
> >> > +Region Access}\label{sec:Virtio Transport Options / Virtio Over
> >> > +PCI Bus / Legacy Interface: Group Member Device Configuration
> >> > +Region Access}
> >> > +
> >> > +The PCI owner device or the member device or both support driver
> >> > +notifications using
> >>
> >> What about
> >>
> >> "The PCI owner device, the member device, or both can choose to
> support..." ?
> >>
> > Fine too.
> > Any thing wrong in having or as above, so I don't write it next time?
> > Or that in current form reads better to me.
>
> Just a bare "support" does not really tell the reader if this is something that is
> required or optional. Dropping the first "or" makes it read better for me.
>
Since this is not normative, Iwill write it as,
The PCI owner device or the member device or both can support
> >
> >> > +a notification region defined in \field{struct
> >> virtio_pci_legacy_notify_region}.
>
> (...)
>
> >> > +The group owner device or the group member device or both MAY
> >> > +support driver notifications region.
> >>
> >> Make this "a driver notification region"?
> >>
> > Notifications are generally more than one and spec has the section "driver
> notifications", so...
>
> I'd parse this as "a region for the purpose of notification" (and "notification
> region" is used above)... but in any case, we need the article here, I think.
Ah ok. I was missing the article, I was thinking to write "driver notifications" vs "driver notification".
Will change to "a driver notifications region" as the article applies to region.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 16:52 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:52 UTC (permalink / raw)
To: Cornelia Huck, virtio-comment, mst, david.edmondson
Cc: virtio-dev, sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Thursday, July 6, 2023 12:47 PM
>
> On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>
> >> From: Cornelia Huck <cohuck@redhat.com>
> >> Sent: Thursday, July 6, 2023 12:28 PM
> >>
> >> On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
> >>
> >> > diff --git a/transport-pci-legacy-regs.tex
> >> > b/transport-pci-legacy-regs.tex new file mode 100644 index
> >> > 0000000..ceea28c
> >> > --- /dev/null
> >> > +++ b/transport-pci-legacy-regs.tex
> >> > @@ -0,0 +1,42 @@
> >> > +\subsection{Legacy Interface: Group member device Configuration
> >> > +Region Access}\label{sec:Virtio Transport Options / Virtio Over
> >> > +PCI Bus / Legacy Interface: Group Member Device Configuration
> >> > +Region Access}
> >> > +
> >> > +The PCI owner device or the member device or both support driver
> >> > +notifications using
> >>
> >> What about
> >>
> >> "The PCI owner device, the member device, or both can choose to
> support..." ?
> >>
> > Fine too.
> > Any thing wrong in having or as above, so I don't write it next time?
> > Or that in current form reads better to me.
>
> Just a bare "support" does not really tell the reader if this is something that is
> required or optional. Dropping the first "or" makes it read better for me.
>
Since this is not normative, Iwill write it as,
The PCI owner device or the member device or both can support
> >
> >> > +a notification region defined in \field{struct
> >> virtio_pci_legacy_notify_region}.
>
> (...)
>
> >> > +The group owner device or the group member device or both MAY
> >> > +support driver notifications region.
> >>
> >> Make this "a driver notification region"?
> >>
> > Notifications are generally more than one and spec has the section "driver
> notifications", so...
>
> I'd parse this as "a region for the purpose of notification" (and "notification
> region" is used above)... but in any case, we need the article here, I think.
Ah ok. I was missing the article, I was thinking to write "driver notifications" vs "driver notification".
Will change to "a driver notifications region" as the article applies to region.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 16:50 ` [virtio-comment] " Michael S. Tsirkin
@ 2023-07-06 16:54 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 12:51 PM
> I don't see a statement that devices MAY support
> VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> with entries returning just owner, just member, or both.
>
Ok. understood.
From the driver notifications wording it didn't imply that it is related to VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY.
Will rewrite as above.
> > Do you suggest to drop above statement?
>
> > >
> > > > > +
> > > > > +For the SR-IOV group type, the owner device supporting
> > > > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > > > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
> > > > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > > > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
> > > > > +VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> > > > > +commands and its member device SHOULD follow the rules for the
> > > > > +PCI Device ID,
> > >
> > > what does "its" mean here? Of the group?
> > Yes, will change to the member device of the group.
> >
> > > Members of the SR-IOV group type are VFs. They can not follow the
> > > rules for the Device ID: the spec says:
> > > This field in all VFs returns FFFFh when read.
> > >
> > > Even if you somehow refer to the software it's extraneous anyway
> > > since the spec proceeds: VI software should return the Vendor ID
> > > value from the associated PF as the Vendor ID value for the VF.
> > >
> > > We'll need a separate statement for Device ID.
> > >
> > Will split the line for Device ID.
> >
> > > > > +Revision ID and Subsystem Device ID of the non-transitional
> > > > > +devices documented in section \ref{sec:Virtio Transport Options
> > > > > +/ Virtio Over PCI
> > > Bus / PCI Device Discovery}.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 16:54 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 12:51 PM
> I don't see a statement that devices MAY support
> VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> with entries returning just owner, just member, or both.
>
Ok. understood.
From the driver notifications wording it didn't imply that it is related to VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY.
Will rewrite as above.
> > Do you suggest to drop above statement?
>
> > >
> > > > > +
> > > > > +For the SR-IOV group type, the owner device supporting
> > > > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> > > > > +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE,
> > > > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> > > > > +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and
> > > > > +VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> > > > > +commands and its member device SHOULD follow the rules for the
> > > > > +PCI Device ID,
> > >
> > > what does "its" mean here? Of the group?
> > Yes, will change to the member device of the group.
> >
> > > Members of the SR-IOV group type are VFs. They can not follow the
> > > rules for the Device ID: the spec says:
> > > This field in all VFs returns FFFFh when read.
> > >
> > > Even if you somehow refer to the software it's extraneous anyway
> > > since the spec proceeds: VI software should return the Vendor ID
> > > value from the associated PF as the Vendor ID value for the VF.
> > >
> > > We'll need a separate statement for Device ID.
> > >
> > Will split the line for Device ID.
> >
> > > > > +Revision ID and Subsystem Device ID of the non-transitional
> > > > > +devices documented in section \ref{sec:Virtio Transport Options
> > > > > +/ Virtio Over PCI
> > > Bus / PCI Device Discovery}.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 16:42 ` [virtio-comment] " Michael S. Tsirkin
@ 2023-07-06 16:58 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:58 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 12:42 PM
>
> We will need to detail how notifications work though. The reason is that the
> legacy notifications are received by owner driver (which is not legacy!) and
> forwarded to device.
> We need to explain exactly how this is done for people who don't read minds
> and did not follow 3 months of mailing list debates, and explain how this has the
> same effect as triggering driver notification through the legacy interface.
>
I am not going to write driver implementation in the spec here.
But I agree some high-level text is needed.
With your suggestions
1. to merge pci and generic in one section,
2. add description to notification,
3. past rewrites provided in v9,
The draft of v11, looks like below. Please see how much more verbose to make it, if at all.
\paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Driver Notifications}
If the group owner device or the group member device support driver
notifications via a memory-mapped operation or I/O operation, these
notifications are sent to the device via accessing such a notification region
using a memory or I/O operation instead of sending the notifications through
the administration command.
The driver of the owner device can send a driver notification to the member
device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
\field{offset} matching \field{Queue Notify} and the \field{data} containing
the virtqueue index to be notified.
However, as many administration commands are used for slow path configuration,
a separate fast path mechanism for such notifications is desired. For the
SR-IOV group type, the optional command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO
addresses this need by returning to the driver one or more addresses which to
be used to send such driver notifications.
In one example, the driver in the hypervisor which intercepts I/O BAR accesses
for the \field{Queue Notify} can access the notification area directly as memory
or I/O access (depending on what the device reported) instead of slow
administration command.
For the command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO the driver sets
\field{opcode} to 0x6.
The driver sets \field{group_member_id} which refers to the member device to be
accessed. This command does not use \field{command_specific_data}.
This command is currently only defined for the SR-IOV group type. When the
device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO command, the group owner
device hardwires VF BAR0 to zero in the SR-IOV Extended capability and the
group member device does not use PCI BAR0 in all the Virtio PCI capabilities
listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 16:58 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 16:58 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 12:42 PM
>
> We will need to detail how notifications work though. The reason is that the
> legacy notifications are received by owner driver (which is not legacy!) and
> forwarded to device.
> We need to explain exactly how this is done for people who don't read minds
> and did not follow 3 months of mailing list debates, and explain how this has the
> same effect as triggering driver notification through the legacy interface.
>
I am not going to write driver implementation in the spec here.
But I agree some high-level text is needed.
With your suggestions
1. to merge pci and generic in one section,
2. add description to notification,
3. past rewrites provided in v9,
The draft of v11, looks like below. Please see how much more verbose to make it, if at all.
\paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Driver Notifications}
If the group owner device or the group member device support driver
notifications via a memory-mapped operation or I/O operation, these
notifications are sent to the device via accessing such a notification region
using a memory or I/O operation instead of sending the notifications through
the administration command.
The driver of the owner device can send a driver notification to the member
device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
\field{offset} matching \field{Queue Notify} and the \field{data} containing
the virtqueue index to be notified.
However, as many administration commands are used for slow path configuration,
a separate fast path mechanism for such notifications is desired. For the
SR-IOV group type, the optional command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO
addresses this need by returning to the driver one or more addresses which to
be used to send such driver notifications.
In one example, the driver in the hypervisor which intercepts I/O BAR accesses
for the \field{Queue Notify} can access the notification area directly as memory
or I/O access (depending on what the device reported) instead of slow
administration command.
For the command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO the driver sets
\field{opcode} to 0x6.
The driver sets \field{group_member_id} which refers to the member device to be
accessed. This command does not use \field{command_specific_data}.
This command is currently only defined for the SR-IOV group type. When the
device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO command, the group owner
device hardwires VF BAR0 to zero in the SR-IOV Extended capability and the
group member device does not use PCI BAR0 in all the Virtio PCI capabilities
listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 16:58 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 17:33 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 17:33 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 04:58:51PM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 12:42 PM
> >
> > We will need to detail how notifications work though. The reason is that the
> > legacy notifications are received by owner driver (which is not legacy!) and
> > forwarded to device.
> > We need to explain exactly how this is done for people who don't read minds
> > and did not follow 3 months of mailing list debates, and explain how this has the
> > same effect as triggering driver notification through the legacy interface.
> >
> I am not going to write driver implementation in the spec here.
> But I agree some high-level text is needed.
> With your suggestions
> 1. to merge pci and generic in one section,
> 2. add description to notification,
> 3. past rewrites provided in v9,
>
> The draft of v11, looks like below. Please see how much more verbose to make it, if at all.
>
> \paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Driver Notifications}
>
> If the group owner device or the group member device support driver
> notifications via a memory-mapped operation or I/O operation, these
> notifications are sent to the device via accessing such a notification region
> using a memory or I/O operation instead of sending the notifications through
> the administration command.
This paragraph adds very little information - just some vague hints at how things work.
> The driver of the owner device can send a driver notification to the member
> device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
> \field{offset} matching \field{Queue Notify} and the \field{data} containing
> the virtqueue index to be notified.
>
> However, as many administration commands are used for slow path configuration,
> a separate fast path mechanism for such notifications is desired. For the
> SR-IOV group type, the optional command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO
> addresses this need by returning to the driver one or more addresses which to
> be used to send such driver notifications.
>
> In one example, the driver in the hypervisor which intercepts I/O BAR accesses
> for the \field{Queue Notify} can access the notification area directly as memory
> or I/O access (depending on what the device reported) instead of slow
> administration command.
>
> For the command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO the driver sets
> \field{opcode} to 0x6.
> The driver sets \field{group_member_id} which refers to the member device to be
> accessed. This command does not use \field{command_specific_data}.
>
> This command is currently only defined for the SR-IOV group type. When the
> device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO command, the group owner
> device hardwires VF BAR0 to zero in the SR-IOV Extended capability and the
> group member device does not use PCI BAR0 in all the Virtio PCI capabilities
> listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
After reading this I still have no clue at how these notifications work.
maybe it's in some other patch. Let's see v11.
Just making a wild guess:
it is true that
to supply a driver notification to the device, it is possible
for the driver to write the vq index of the vq to be notified, in little
endian format, using a single 16 byte write at the address provided ?
and I am guessing that
the write is an IO or a memory write, depending on the
type of the BAR referred to?
then why don't we just say this?
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 17:33 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 17:33 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 04:58:51PM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 12:42 PM
> >
> > We will need to detail how notifications work though. The reason is that the
> > legacy notifications are received by owner driver (which is not legacy!) and
> > forwarded to device.
> > We need to explain exactly how this is done for people who don't read minds
> > and did not follow 3 months of mailing list debates, and explain how this has the
> > same effect as triggering driver notification through the legacy interface.
> >
> I am not going to write driver implementation in the spec here.
> But I agree some high-level text is needed.
> With your suggestions
> 1. to merge pci and generic in one section,
> 2. add description to notification,
> 3. past rewrites provided in v9,
>
> The draft of v11, looks like below. Please see how much more verbose to make it, if at all.
>
> \paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Driver Notifications}
>
> If the group owner device or the group member device support driver
> notifications via a memory-mapped operation or I/O operation, these
> notifications are sent to the device via accessing such a notification region
> using a memory or I/O operation instead of sending the notifications through
> the administration command.
This paragraph adds very little information - just some vague hints at how things work.
> The driver of the owner device can send a driver notification to the member
> device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
> \field{offset} matching \field{Queue Notify} and the \field{data} containing
> the virtqueue index to be notified.
>
> However, as many administration commands are used for slow path configuration,
> a separate fast path mechanism for such notifications is desired. For the
> SR-IOV group type, the optional command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO
> addresses this need by returning to the driver one or more addresses which to
> be used to send such driver notifications.
>
> In one example, the driver in the hypervisor which intercepts I/O BAR accesses
> for the \field{Queue Notify} can access the notification area directly as memory
> or I/O access (depending on what the device reported) instead of slow
> administration command.
>
> For the command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO the driver sets
> \field{opcode} to 0x6.
> The driver sets \field{group_member_id} which refers to the member device to be
> accessed. This command does not use \field{command_specific_data}.
>
> This command is currently only defined for the SR-IOV group type. When the
> device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO command, the group owner
> device hardwires VF BAR0 to zero in the SR-IOV Extended capability and the
> group member device does not use PCI BAR0 in all the Virtio PCI capabilities
> listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
After reading this I still have no clue at how these notifications work.
maybe it's in some other patch. Let's see v11.
Just making a wild guess:
it is true that
to supply a driver notification to the device, it is possible
for the driver to write the vq index of the vq to be notified, in little
endian format, using a single 16 byte write at the address provided ?
and I am guessing that
the write is an IO or a memory write, depending on the
type of the BAR referred to?
then why don't we just say this?
--
MST
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 16:58 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 17:38 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 17:38 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 04:58:51PM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 12:42 PM
> >
> > We will need to detail how notifications work though. The reason is that the
> > legacy notifications are received by owner driver (which is not legacy!) and
> > forwarded to device.
> > We need to explain exactly how this is done for people who don't read minds
> > and did not follow 3 months of mailing list debates, and explain how this has the
> > same effect as triggering driver notification through the legacy interface.
> >
> I am not going to write driver implementation in the spec here.
> But I agree some high-level text is needed.
> With your suggestions
> 1. to merge pci and generic in one section,
> 2. add description to notification,
> 3. past rewrites provided in v9,
>
> The draft of v11, looks like below. Please see how much more verbose to make it, if at all.
>
> \paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Driver Notifications}
>
> If the group owner device or the group member device support driver
> notifications via a memory-mapped operation or I/O operation, these
> notifications are sent to the device via accessing such a notification region
> using a memory or I/O operation instead of sending the notifications through
> the administration command.
>
> The driver of the owner device can send a driver notification to the member
> device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
> \field{offset} matching \field{Queue Notify} and the \field{data} containing
> the virtqueue index to be notified.
>
> However, as many administration commands are used for slow path configuration,
> a separate fast path mechanism for such notifications is desired. For the
> SR-IOV group type, the optional command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO
> addresses this need by returning to the driver one or more addresses which to
> be used to send such driver notifications.
>
> In one example, the driver in the hypervisor which intercepts I/O BAR accesses
> for the \field{Queue Notify} can access the notification area directly as memory
> or I/O access (depending on what the device reported) instead of slow
> administration command.
>
> For the command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO the driver sets
> \field{opcode} to 0x6.
> The driver sets \field{group_member_id} which refers to the member device to be
> accessed. This command does not use \field{command_specific_data}.
>
> This command is currently only defined for the SR-IOV group type. When the
> device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO command, the group owner
> device hardwires VF BAR0 to zero in the SR-IOV Extended capability and the
> group member device does not use PCI BAR0 in all the Virtio PCI capabilities
> listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
lots of comments wrt grammar. do post v11 and i will fix.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 17:38 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 17:38 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 04:58:51PM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 12:42 PM
> >
> > We will need to detail how notifications work though. The reason is that the
> > legacy notifications are received by owner driver (which is not legacy!) and
> > forwarded to device.
> > We need to explain exactly how this is done for people who don't read minds
> > and did not follow 3 months of mailing list debates, and explain how this has the
> > same effect as triggering driver notification through the legacy interface.
> >
> I am not going to write driver implementation in the spec here.
> But I agree some high-level text is needed.
> With your suggestions
> 1. to merge pci and generic in one section,
> 2. add description to notification,
> 3. past rewrites provided in v9,
>
> The draft of v11, looks like below. Please see how much more verbose to make it, if at all.
>
> \paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Legacy Interface / Legacy Driver Notifications}
>
> If the group owner device or the group member device support driver
> notifications via a memory-mapped operation or I/O operation, these
> notifications are sent to the device via accessing such a notification region
> using a memory or I/O operation instead of sending the notifications through
> the administration command.
>
> The driver of the owner device can send a driver notification to the member
> device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
> \field{offset} matching \field{Queue Notify} and the \field{data} containing
> the virtqueue index to be notified.
>
> However, as many administration commands are used for slow path configuration,
> a separate fast path mechanism for such notifications is desired. For the
> SR-IOV group type, the optional command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO
> addresses this need by returning to the driver one or more addresses which to
> be used to send such driver notifications.
>
> In one example, the driver in the hypervisor which intercepts I/O BAR accesses
> for the \field{Queue Notify} can access the notification area directly as memory
> or I/O access (depending on what the device reported) instead of slow
> administration command.
>
> For the command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO the driver sets
> \field{opcode} to 0x6.
> The driver sets \field{group_member_id} which refers to the member device to be
> accessed. This command does not use \field{command_specific_data}.
>
> This command is currently only defined for the SR-IOV group type. When the
> device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO command, the group owner
> device hardwires VF BAR0 to zero in the SR-IOV Extended capability and the
> group member device does not use PCI BAR0 in all the Virtio PCI capabilities
> listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
lots of comments wrt grammar. do post v11 and i will fix.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 17:33 ` [virtio-comment] " Michael S. Tsirkin
@ 2023-07-06 17:47 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 17:47 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 1:34 PM
>
> On Thu, Jul 06, 2023 at 04:58:51PM +0000, Parav Pandit wrote:
> >
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Thursday, July 6, 2023 12:42 PM
> > >
> > > We will need to detail how notifications work though. The reason is
> > > that the legacy notifications are received by owner driver (which is
> > > not legacy!) and forwarded to device.
> > > We need to explain exactly how this is done for people who don't
> > > read minds and did not follow 3 months of mailing list debates, and
> > > explain how this has the same effect as triggering driver notification through
> the legacy interface.
> > >
> > I am not going to write driver implementation in the spec here.
> > But I agree some high-level text is needed.
> > With your suggestions
> > 1. to merge pci and generic in one section, 2. add description to
> > notification, 3. past rewrites provided in v9,
> >
> > The draft of v11, looks like below. Please see how much more verbose to make
> it, if at all.
> >
> > \paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a
> > Virtio Device / Device groups / Group administration commands / Legacy
> > Interface / Legacy Driver Notifications}
> >
> > If the group owner device or the group member device support driver
> > notifications via a memory-mapped operation or I/O operation, these
> > notifications are sent to the device via accessing such a notification
> > region using a memory or I/O operation instead of sending the
> > notifications through the administration command.
>
> This paragraph adds very little information - just some vague hints at how things
> work.
>
A hunk added this paragraph back.
Going to remove it as description is duplicate of what is written below.
> > The driver of the owner device can send a driver notification to the
> > member device by executing
> VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE
> > with the \field{offset} matching \field{Queue Notify} and the
> > \field{data} containing the virtqueue index to be notified.
> >
> > However, as many administration commands are used for slow path
> > configuration, a separate fast path mechanism for such notifications
> > is desired. For the SR-IOV group type, the optional command
> > VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO
> > addresses this need by returning to the driver one or more addresses
> > which to be used to send such driver notifications.
> >
> > In one example, the driver in the hypervisor which intercepts I/O BAR
> > accesses for the \field{Queue Notify} can access the notification area
> > directly as memory or I/O access (depending on what the device
> > reported) instead of slow administration command.
> >
Above paragraph is really more than enough for the reader to implement.
I will merge your text of 16-bit notify vq line here.
> > For the command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO the driver
> sets
> > \field{opcode} to 0x6.
> > The driver sets \field{group_member_id} which refers to the member
> > device to be accessed. This command does not use
> \field{command_specific_data}.
> >
> > This command is currently only defined for the SR-IOV group type. When
> > the device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO command,
> the
> > group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
> > capability and the group member device does not use PCI BAR0 in all
> > the Virtio PCI capabilities listed in section \ref{sec:Virtio Transport Options /
> Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
>
> After reading this I still have no clue at how these notifications work.
> maybe it's in some other patch. Let's see v11.
>
There is only one patch now in v11 other than two fixes.
> Just making a wild guess:
>
> it is true that
> to supply a driver notification to the device, it is possible for the driver
> to write the vq index of the vq to be notified, in little endian format, using a
> single 16 byte write at the address provided ?
>
> and I am guessing that
> the write is an IO or a memory write, depending on the
> type of the BAR referred to?
>
> then why don't we just say this?
All this while I assume that what you wrote above is already written in description for "queue notify" register in " Legacy Interfaces: A Note on PCI Device Layout".
So no need to repeat.
But I realized that base spec is totally silent on it, but still we are supposed to write here.
Ok.
So yes, let me add above line here, without touching existing legacy interface section.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 17:47 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 17:47 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 1:34 PM
>
> On Thu, Jul 06, 2023 at 04:58:51PM +0000, Parav Pandit wrote:
> >
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Thursday, July 6, 2023 12:42 PM
> > >
> > > We will need to detail how notifications work though. The reason is
> > > that the legacy notifications are received by owner driver (which is
> > > not legacy!) and forwarded to device.
> > > We need to explain exactly how this is done for people who don't
> > > read minds and did not follow 3 months of mailing list debates, and
> > > explain how this has the same effect as triggering driver notification through
> the legacy interface.
> > >
> > I am not going to write driver implementation in the spec here.
> > But I agree some high-level text is needed.
> > With your suggestions
> > 1. to merge pci and generic in one section, 2. add description to
> > notification, 3. past rewrites provided in v9,
> >
> > The draft of v11, looks like below. Please see how much more verbose to make
> it, if at all.
> >
> > \paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a
> > Virtio Device / Device groups / Group administration commands / Legacy
> > Interface / Legacy Driver Notifications}
> >
> > If the group owner device or the group member device support driver
> > notifications via a memory-mapped operation or I/O operation, these
> > notifications are sent to the device via accessing such a notification
> > region using a memory or I/O operation instead of sending the
> > notifications through the administration command.
>
> This paragraph adds very little information - just some vague hints at how things
> work.
>
A hunk added this paragraph back.
Going to remove it as description is duplicate of what is written below.
> > The driver of the owner device can send a driver notification to the
> > member device by executing
> VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE
> > with the \field{offset} matching \field{Queue Notify} and the
> > \field{data} containing the virtqueue index to be notified.
> >
> > However, as many administration commands are used for slow path
> > configuration, a separate fast path mechanism for such notifications
> > is desired. For the SR-IOV group type, the optional command
> > VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO
> > addresses this need by returning to the driver one or more addresses
> > which to be used to send such driver notifications.
> >
> > In one example, the driver in the hypervisor which intercepts I/O BAR
> > accesses for the \field{Queue Notify} can access the notification area
> > directly as memory or I/O access (depending on what the device
> > reported) instead of slow administration command.
> >
Above paragraph is really more than enough for the reader to implement.
I will merge your text of 16-bit notify vq line here.
> > For the command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO the driver
> sets
> > \field{opcode} to 0x6.
> > The driver sets \field{group_member_id} which refers to the member
> > device to be accessed. This command does not use
> \field{command_specific_data}.
> >
> > This command is currently only defined for the SR-IOV group type. When
> > the device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO command,
> the
> > group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
> > capability and the group member device does not use PCI BAR0 in all
> > the Virtio PCI capabilities listed in section \ref{sec:Virtio Transport Options /
> Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
>
> After reading this I still have no clue at how these notifications work.
> maybe it's in some other patch. Let's see v11.
>
There is only one patch now in v11 other than two fixes.
> Just making a wild guess:
>
> it is true that
> to supply a driver notification to the device, it is possible for the driver
> to write the vq index of the vq to be notified, in little endian format, using a
> single 16 byte write at the address provided ?
>
> and I am guessing that
> the write is an IO or a memory write, depending on the
> type of the BAR referred to?
>
> then why don't we just say this?
All this while I assume that what you wrote above is already written in description for "queue notify" register in " Legacy Interfaces: A Note on PCI Device Layout".
So no need to repeat.
But I realized that base spec is totally silent on it, but still we are supposed to write here.
Ok.
So yes, let me add above line here, without touching existing legacy interface section.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 17:47 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 18:06 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 18:06 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 05:47:08PM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 1:34 PM
> >
> > On Thu, Jul 06, 2023 at 04:58:51PM +0000, Parav Pandit wrote:
> > >
> > >
> > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > Sent: Thursday, July 6, 2023 12:42 PM
> > > >
> > > > We will need to detail how notifications work though. The reason is
> > > > that the legacy notifications are received by owner driver (which is
> > > > not legacy!) and forwarded to device.
> > > > We need to explain exactly how this is done for people who don't
> > > > read minds and did not follow 3 months of mailing list debates, and
> > > > explain how this has the same effect as triggering driver notification through
> > the legacy interface.
> > > >
> > > I am not going to write driver implementation in the spec here.
> > > But I agree some high-level text is needed.
> > > With your suggestions
> > > 1. to merge pci and generic in one section, 2. add description to
> > > notification, 3. past rewrites provided in v9,
> > >
> > > The draft of v11, looks like below. Please see how much more verbose to make
> > it, if at all.
> > >
> > > \paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a
> > > Virtio Device / Device groups / Group administration commands / Legacy
> > > Interface / Legacy Driver Notifications}
> > >
> > > If the group owner device or the group member device support driver
> > > notifications via a memory-mapped operation or I/O operation, these
> > > notifications are sent to the device via accessing such a notification
> > > region using a memory or I/O operation instead of sending the
> > > notifications through the administration command.
> >
> > This paragraph adds very little information - just some vague hints at how things
> > work.
> >
> A hunk added this paragraph back.
> Going to remove it as description is duplicate of what is written below.
>
> > > The driver of the owner device can send a driver notification to the
> > > member device by executing
> > VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE
> > > with the \field{offset} matching \field{Queue Notify} and the
> > > \field{data} containing the virtqueue index to be notified.
> > >
> > > However, as many administration commands are used for slow path
> > > configuration, a separate fast path mechanism for such notifications
> > > is desired. For the SR-IOV group type, the optional command
> > > VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO
> > > addresses this need by returning to the driver one or more addresses
> > > which to be used to send such driver notifications.
> > >
> > > In one example, the driver in the hypervisor which intercepts I/O BAR
> > > accesses for the \field{Queue Notify} can access the notification area
> > > directly as memory or I/O access (depending on what the device
> > > reported) instead of slow administration command.
> > >
> Above paragraph is really more than enough for the reader to implement.
> I will merge your text of 16-bit notify vq line here.
I don't have all of the context in front of me. We'll see in v11.
Try to keep a style consistent with what we have written
for the config space.
> > > For the command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO the driver
> > sets
> > > \field{opcode} to 0x6.
> > > The driver sets \field{group_member_id} which refers to the member
> > > device to be accessed. This command does not use
> > \field{command_specific_data}.
> > >
> > > This command is currently only defined for the SR-IOV group type. When
> > > the device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO command,
> > the
> > > group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
> > > capability and the group member device does not use PCI BAR0 in all
> > > the Virtio PCI capabilities listed in section \ref{sec:Virtio Transport Options /
> > Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
> >
> > After reading this I still have no clue at how these notifications work.
> > maybe it's in some other patch. Let's see v11.
> >
> There is only one patch now in v11 other than two fixes.
>
> > Just making a wild guess:
> >
> > it is true that
> > to supply a driver notification to the device, it is possible for the driver
> > to write the vq index of the vq to be notified, in little endian format, using a
> > single 16 byte write at the address provided ?
> >
> > and I am guessing that
> > the write is an IO or a memory write, depending on the
> > type of the BAR referred to?
> >
> > then why don't we just say this?
> All this while I assume that what you wrote above is already written in description for "queue notify" register in " Legacy Interfaces: A Note on PCI Device Layout".
> So no need to repeat.
>
> But I realized that base spec is totally silent on it, but still we are supposed to write here.
> Ok.
> So yes, let me add above line here, without touching existing legacy interface section.
It's not documented all that well. I think it was clearer originally
but with all the VIRTIO_F_NOTIFICATION_DATA and such it bit-rotted.
But again even if you add it there, you can not claim it's exactly the
same as legacy because the address is different, the address type is
different, the driver is different (this is owner driver) and even
the device is different.
Please also call out the unusual configuration where the type
is "member" and then you have the owner driver access the
memory of the member device. People might be confused.
I also think we should explain that order of entries is a hint
to driver: use the 1st entry that you can.
--
MST
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 18:06 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 18:06 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 05:47:08PM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 1:34 PM
> >
> > On Thu, Jul 06, 2023 at 04:58:51PM +0000, Parav Pandit wrote:
> > >
> > >
> > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > Sent: Thursday, July 6, 2023 12:42 PM
> > > >
> > > > We will need to detail how notifications work though. The reason is
> > > > that the legacy notifications are received by owner driver (which is
> > > > not legacy!) and forwarded to device.
> > > > We need to explain exactly how this is done for people who don't
> > > > read minds and did not follow 3 months of mailing list debates, and
> > > > explain how this has the same effect as triggering driver notification through
> > the legacy interface.
> > > >
> > > I am not going to write driver implementation in the spec here.
> > > But I agree some high-level text is needed.
> > > With your suggestions
> > > 1. to merge pci and generic in one section, 2. add description to
> > > notification, 3. past rewrites provided in v9,
> > >
> > > The draft of v11, looks like below. Please see how much more verbose to make
> > it, if at all.
> > >
> > > \paragraph{Legacy Driver Notification}\label{par:Basic Facilities of a
> > > Virtio Device / Device groups / Group administration commands / Legacy
> > > Interface / Legacy Driver Notifications}
> > >
> > > If the group owner device or the group member device support driver
> > > notifications via a memory-mapped operation or I/O operation, these
> > > notifications are sent to the device via accessing such a notification
> > > region using a memory or I/O operation instead of sending the
> > > notifications through the administration command.
> >
> > This paragraph adds very little information - just some vague hints at how things
> > work.
> >
> A hunk added this paragraph back.
> Going to remove it as description is duplicate of what is written below.
>
> > > The driver of the owner device can send a driver notification to the
> > > member device by executing
> > VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE
> > > with the \field{offset} matching \field{Queue Notify} and the
> > > \field{data} containing the virtqueue index to be notified.
> > >
> > > However, as many administration commands are used for slow path
> > > configuration, a separate fast path mechanism for such notifications
> > > is desired. For the SR-IOV group type, the optional command
> > > VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO
> > > addresses this need by returning to the driver one or more addresses
> > > which to be used to send such driver notifications.
> > >
> > > In one example, the driver in the hypervisor which intercepts I/O BAR
> > > accesses for the \field{Queue Notify} can access the notification area
> > > directly as memory or I/O access (depending on what the device
> > > reported) instead of slow administration command.
> > >
> Above paragraph is really more than enough for the reader to implement.
> I will merge your text of 16-bit notify vq line here.
I don't have all of the context in front of me. We'll see in v11.
Try to keep a style consistent with what we have written
for the config space.
> > > For the command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO the driver
> > sets
> > > \field{opcode} to 0x6.
> > > The driver sets \field{group_member_id} which refers to the member
> > > device to be accessed. This command does not use
> > \field{command_specific_data}.
> > >
> > > This command is currently only defined for the SR-IOV group type. When
> > > the device supports VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO command,
> > the
> > > group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
> > > capability and the group member device does not use PCI BAR0 in all
> > > the Virtio PCI capabilities listed in section \ref{sec:Virtio Transport Options /
> > Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
> >
> > After reading this I still have no clue at how these notifications work.
> > maybe it's in some other patch. Let's see v11.
> >
> There is only one patch now in v11 other than two fixes.
>
> > Just making a wild guess:
> >
> > it is true that
> > to supply a driver notification to the device, it is possible for the driver
> > to write the vq index of the vq to be notified, in little endian format, using a
> > single 16 byte write at the address provided ?
> >
> > and I am guessing that
> > the write is an IO or a memory write, depending on the
> > type of the BAR referred to?
> >
> > then why don't we just say this?
> All this while I assume that what you wrote above is already written in description for "queue notify" register in " Legacy Interfaces: A Note on PCI Device Layout".
> So no need to repeat.
>
> But I realized that base spec is totally silent on it, but still we are supposed to write here.
> Ok.
> So yes, let me add above line here, without touching existing legacy interface section.
It's not documented all that well. I think it was clearer originally
but with all the VIRTIO_F_NOTIFICATION_DATA and such it bit-rotted.
But again even if you add it there, you can not claim it's exactly the
same as legacy because the address is different, the address type is
different, the driver is different (this is owner driver) and even
the device is different.
Please also call out the unusual configuration where the type
is "member" and then you have the owner driver access the
memory of the member device. People might be confused.
I also think we should explain that order of entries is a hint
to driver: use the 1st entry that you can.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 18:06 ` [virtio-dev] " Michael S. Tsirkin
@ 2023-07-06 18:16 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 18:16 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 2:06 PM
>
> But again even if you add it there, you can not claim it's exactly the same as
> legacy because the address is different, the address type is different, the driver
> is different (this is owner driver) and even the device is different.
>
You drafted below, that I included,
The driver of the owner device can send a driver notification to the member
device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
\field{offset} matching \field{Queue Notify} and the \field{data} containing
the virtqueue index to be notified.
We extend this further by saying Queue notify notifications is sent via MMIO as,
The driver of the owner device can send a driver notification to the member
device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
\field{offset} matching \field{Queue Notify} and the \field{data} containing
the virtqueue index to be notified or by performing memory or I/O write in
the any of the notification region at offset 0 supplied by the device in
VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO result.
> Please also call out the unusual configuration where the type is "member" and
> then you have the owner driver access the memory of the member device.
> People might be confused.
>
> I also think we should explain that order of entries is a hint to driver: use the 1st
> entry that you can.
Driver really can choose any valid entry out of the 4 that driver likes.
I really don't see a need for overwriting this area as I fail to see why one will expose multiple entries from the device side in reality.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 18:16 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 18:16 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 2:06 PM
>
> But again even if you add it there, you can not claim it's exactly the same as
> legacy because the address is different, the address type is different, the driver
> is different (this is owner driver) and even the device is different.
>
You drafted below, that I included,
The driver of the owner device can send a driver notification to the member
device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
\field{offset} matching \field{Queue Notify} and the \field{data} containing
the virtqueue index to be notified.
We extend this further by saying Queue notify notifications is sent via MMIO as,
The driver of the owner device can send a driver notification to the member
device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
\field{offset} matching \field{Queue Notify} and the \field{data} containing
the virtqueue index to be notified or by performing memory or I/O write in
the any of the notification region at offset 0 supplied by the device in
VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO result.
> Please also call out the unusual configuration where the type is "member" and
> then you have the owner driver access the memory of the member device.
> People might be confused.
>
> I also think we should explain that order of entries is a hint to driver: use the 1st
> entry that you can.
Driver really can choose any valid entry out of the 4 that driver likes.
I really don't see a need for overwriting this area as I fail to see why one will expose multiple entries from the device side in reality.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 18:16 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 18:48 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 18:48 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 06:16:10PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 2:06 PM
> >
> > But again even if you add it there, you can not claim it's exactly the same as
> > legacy because the address is different, the address type is different, the driver
> > is different (this is owner driver) and even the device is different.
> >
> You drafted below, that I included,
>
> The driver of the owner device can send a driver notification to the member
> device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
> \field{offset} matching \field{Queue Notify} and the \field{data} containing
> the virtqueue index to be notified.
>
> We extend this further by saying Queue notify notifications is sent via MMIO as,
>
> The driver of the owner device can send a driver notification to the member
> device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
> \field{offset} matching \field{Queue Notify} and the \field{data} containing
> the virtqueue index to be notified or by performing memory or I/O write in
split to two sentences please. E.g.
Alternatively, the driver ...
> the any of the notification region at offset 0 supplied by the device in
the any is agrammatical
> VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO result.
>
> > Please also call out the unusual configuration where the type is "member" and
> > then you have the owner driver access the memory of the member device.
> > People might be confused.
> >
> > I also think we should explain that order of entries is a hint to driver: use the 1st
> > entry that you can.
>
> Driver really can choose any valid entry out of the 4 that driver likes.
> I really don't see a need for overwriting this area as I fail to see why one will expose multiple entries from the device side in reality.
I do: one for owner one for member.
which is best for device is device specific.
I don't know what do you mean by "overwriting". Explaining in detail?
You feel like this because you spent a lot of time thinking
about the area and there is a specific solution is very clear in your head.
First readers are not like this and second they might have a
different solution.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 18:48 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 18:48 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 06:16:10PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 2:06 PM
> >
> > But again even if you add it there, you can not claim it's exactly the same as
> > legacy because the address is different, the address type is different, the driver
> > is different (this is owner driver) and even the device is different.
> >
> You drafted below, that I included,
>
> The driver of the owner device can send a driver notification to the member
> device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
> \field{offset} matching \field{Queue Notify} and the \field{data} containing
> the virtqueue index to be notified.
>
> We extend this further by saying Queue notify notifications is sent via MMIO as,
>
> The driver of the owner device can send a driver notification to the member
> device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
> \field{offset} matching \field{Queue Notify} and the \field{data} containing
> the virtqueue index to be notified or by performing memory or I/O write in
split to two sentences please. E.g.
Alternatively, the driver ...
> the any of the notification region at offset 0 supplied by the device in
the any is agrammatical
> VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO result.
>
> > Please also call out the unusual configuration where the type is "member" and
> > then you have the owner driver access the memory of the member device.
> > People might be confused.
> >
> > I also think we should explain that order of entries is a hint to driver: use the 1st
> > entry that you can.
>
> Driver really can choose any valid entry out of the 4 that driver likes.
> I really don't see a need for overwriting this area as I fail to see why one will expose multiple entries from the device side in reality.
I do: one for owner one for member.
which is best for device is device specific.
I don't know what do you mean by "overwriting". Explaining in detail?
You feel like this because you spent a lot of time thinking
about the area and there is a specific solution is very clear in your head.
First readers are not like this and second they might have a
different solution.
--
MST
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 18:48 ` [virtio-comment] " Michael S. Tsirkin
@ 2023-07-06 18:53 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 18:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 2:48 PM
> > The driver of the owner device can send a driver notification to the
> > member device by executing
> VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE
> > with the \field{offset} matching \field{Queue Notify} and the
> > \field{data} containing the virtqueue index to be notified or by
> > performing memory or I/O write in
>
> split to two sentences please. E.g.
> Alternatively, the driver ...
>
Ack.
Moving to it dedicated para, as in this first para the notification region and command is not yet introduced.
> > the any of the notification region at offset 0 supplied by the device
> > in
>
> the any is agrammatical
>
> > VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO result.
> >
> > > Please also call out the unusual configuration where the type is
> > > "member" and then you have the owner driver access the memory of the
> member device.
> > > People might be confused.
> > >
> > > I also think we should explain that order of entries is a hint to
> > > driver: use the 1st entry that you can.
> >
> > Driver really can choose any valid entry out of the 4 that driver likes.
> > I really don't see a need for overwriting this area as I fail to see why one will
> expose multiple entries from the device side in reality.
>
> I do: one for owner one for member.
Yes, I am aware of choice or multi-entry. :)
> which is best for device is device specific.
>
> I don't know what do you mean by "overwriting". Explaining in detail?
:) being too verbose than needed.
> You feel like this because you spent a lot of time thinking about the area and
> there is a specific solution is very clear in your head.
> First readers are not like this and second they might have a different solution.
I am just saying to keep things simple. Let driver choose any entry it wants to use instead of device deciding on priority and hints etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 18:53 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 18:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 2:48 PM
> > The driver of the owner device can send a driver notification to the
> > member device by executing
> VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE
> > with the \field{offset} matching \field{Queue Notify} and the
> > \field{data} containing the virtqueue index to be notified or by
> > performing memory or I/O write in
>
> split to two sentences please. E.g.
> Alternatively, the driver ...
>
Ack.
Moving to it dedicated para, as in this first para the notification region and command is not yet introduced.
> > the any of the notification region at offset 0 supplied by the device
> > in
>
> the any is agrammatical
>
> > VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO result.
> >
> > > Please also call out the unusual configuration where the type is
> > > "member" and then you have the owner driver access the memory of the
> member device.
> > > People might be confused.
> > >
> > > I also think we should explain that order of entries is a hint to
> > > driver: use the 1st entry that you can.
> >
> > Driver really can choose any valid entry out of the 4 that driver likes.
> > I really don't see a need for overwriting this area as I fail to see why one will
> expose multiple entries from the device side in reality.
>
> I do: one for owner one for member.
Yes, I am aware of choice or multi-entry. :)
> which is best for device is device specific.
>
> I don't know what do you mean by "overwriting". Explaining in detail?
:) being too verbose than needed.
> You feel like this because you spent a lot of time thinking about the area and
> there is a specific solution is very clear in your head.
> First readers are not like this and second they might have a different solution.
I am just saying to keep things simple. Let driver choose any entry it wants to use instead of device deciding on priority and hints etc.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 18:53 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 18:56 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 18:56 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 06:53:55PM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 2:48 PM
>
>
> > > The driver of the owner device can send a driver notification to the
> > > member device by executing
> > VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE
> > > with the \field{offset} matching \field{Queue Notify} and the
> > > \field{data} containing the virtqueue index to be notified or by
> > > performing memory or I/O write in
> >
> > split to two sentences please. E.g.
> > Alternatively, the driver ...
> >
> Ack.
> Moving to it dedicated para, as in this first para the notification region and command is not yet introduced.
>
> > > the any of the notification region at offset 0 supplied by the device
> > > in
> >
> > the any is agrammatical
> >
> > > VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO result.
> > >
> > > > Please also call out the unusual configuration where the type is
> > > > "member" and then you have the owner driver access the memory of the
> > member device.
> > > > People might be confused.
> > > >
> > > > I also think we should explain that order of entries is a hint to
> > > > driver: use the 1st entry that you can.
> > >
> > > Driver really can choose any valid entry out of the 4 that driver likes.
> > > I really don't see a need for overwriting this area as I fail to see why one will
> > expose multiple entries from the device side in reality.
> >
> > I do: one for owner one for member.
> Yes, I am aware of choice or multi-entry. :)
>
> > which is best for device is device specific.
> >
> > I don't know what do you mean by "overwriting". Explaining in detail?
> :) being too verbose than needed.
>
> > You feel like this because you spent a lot of time thinking about the area and
> > there is a specific solution is very clear in your head.
> > First readers are not like this and second they might have a different solution.
>
> I am just saying to keep things simple. Let driver choose any entry it wants to use instead of device deciding on priority and hints etc.
Let's say driver can support both types which to choose?
As the order is there anyway, why not just prescribe entries are
used in order?
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 18:56 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 18:56 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 06:53:55PM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 2:48 PM
>
>
> > > The driver of the owner device can send a driver notification to the
> > > member device by executing
> > VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE
> > > with the \field{offset} matching \field{Queue Notify} and the
> > > \field{data} containing the virtqueue index to be notified or by
> > > performing memory or I/O write in
> >
> > split to two sentences please. E.g.
> > Alternatively, the driver ...
> >
> Ack.
> Moving to it dedicated para, as in this first para the notification region and command is not yet introduced.
>
> > > the any of the notification region at offset 0 supplied by the device
> > > in
> >
> > the any is agrammatical
> >
> > > VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO result.
> > >
> > > > Please also call out the unusual configuration where the type is
> > > > "member" and then you have the owner driver access the memory of the
> > member device.
> > > > People might be confused.
> > > >
> > > > I also think we should explain that order of entries is a hint to
> > > > driver: use the 1st entry that you can.
> > >
> > > Driver really can choose any valid entry out of the 4 that driver likes.
> > > I really don't see a need for overwriting this area as I fail to see why one will
> > expose multiple entries from the device side in reality.
> >
> > I do: one for owner one for member.
> Yes, I am aware of choice or multi-entry. :)
>
> > which is best for device is device specific.
> >
> > I don't know what do you mean by "overwriting". Explaining in detail?
> :) being too verbose than needed.
>
> > You feel like this because you spent a lot of time thinking about the area and
> > there is a specific solution is very clear in your head.
> > First readers are not like this and second they might have a different solution.
>
> I am just saying to keep things simple. Let driver choose any entry it wants to use instead of device deciding on priority and hints etc.
Let's say driver can support both types which to choose?
As the order is there anyway, why not just prescribe entries are
used in order?
--
MST
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 18:56 ` [virtio-comment] " Michael S. Tsirkin
@ 2023-07-06 19:00 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 19:00 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 2:57 PM
> > I am just saying to keep things simple. Let driver choose any entry it wants to
> use instead of device deciding on priority and hints etc.
>
> Let's say driver can support both types which to choose?
Any entry that driver likes.
> As the order is there anyway, why not just prescribe entries are used in order?
I don't see any value in defining any order. It is an array of entries not a priority list.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 19:00 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 19:00 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 2:57 PM
> > I am just saying to keep things simple. Let driver choose any entry it wants to
> use instead of device deciding on priority and hints etc.
>
> Let's say driver can support both types which to choose?
Any entry that driver likes.
> As the order is there anyway, why not just prescribe entries are used in order?
I don't see any value in defining any order. It is an array of entries not a priority list.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 19:00 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 19:00 UTC (permalink / raw)
To: Parav Pandit
Cc: virtio-comment, cohuck, david.edmondson, virtio-dev, sburla,
jasowang, yishaih, maorg, shahafs
On Thu, Jul 06, 2023 at 07:17:14AM +0300, Parav Pandit wrote:
> This patch links how in a PCI transport a group owner can access group
> member (PCI VFs) legacy registers using a legacy registers access
> commands using administration virtqueue infrastructure.
>
> Additionally it extend the PCI notification capability through which a
> PCI VF device indicates to the driver which PCI BAR region to be used
> for driver notifications.
>
> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/167
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
> changelog:
> v9->v10:
> - addressed comments from Cornelia
> - fixed errors related to article
> - hardwire to hardwires
> - replaced various to all
> - added hardwire to zero
> v7->v8:
> - addressed comments from Michael
> - made bar offset 64-bit
> - prefix legacy specific structure with _legacy
> - moved generic normative from pci to generic section
> - added link to virtio pci capabilities when referring to bar 0
> - remove 'should' from generic description
> v6->v7:
> - addressed comments from Michael
> - removed driver normative about I/O BAR emulation as it does not
> make much sense for the spec
> - removed references to administration virtqueue
> - rewrote driver legacy region access without guest and hypervisor
> wording
> - added normative for notification region
> - added normative for PCI IDs for device which support legacy commands
> v5->v6:
> - aligned pci capability to 4B as required by PCI spec
> - added text for the PCI capability for the group member device
> v4->v5:
> - split pci transport and generic command section to new patch
> - removed multiple references to the VF
> - written the description of the command as generic with member
> and group device terminology
> - reflected many section names to remove VF
> v3->v4:
> - moved noted to the conformance section details in next patch
> - removed queue notify address query AQ command on Michael's suggestion,
> though it is fine. Instead replaced with extending virtio_pci_notify_cap
> to indicate that legacy queue notifications can be done on the
> notification location.
> - fixed spelling errors.
> - replaced administrative virtqueue to administration virtqueue
> - added queue notification capability register to indicate legacy q
> notification supported
> v2->v3:
> - adddressed Jason and Michael's comment to split single register
> access command to common config and device specific commands.
> - dropped the suggetion to introduce enable/disable command as
> admin command cap bit already covers it.
> v1->v2:
> - addressed comments from Michael
> - added theory of operation
> - grammar corrections
> - removed group fields description from individual commands as
> it is already present in generic section
> - added endianness normative for legacy device registers region
> - renamed the file to drop vf and add legacy prefix
>
> - added overview in commit log
> - renamed subsection to reflect command
> ---
> admin-cmds-legacy-interface.tex | 3 ++-
> conformance.tex | 1 +
> transport-pci-legacy-regs.tex | 42 +++++++++++++++++++++++++++++++++
> transport-pci.tex | 2 ++
> 4 files changed, 47 insertions(+), 1 deletion(-)
> create mode 100644 transport-pci-legacy-regs.tex
>
> diff --git a/admin-cmds-legacy-interface.tex b/admin-cmds-legacy-interface.tex
> index dd01c0a..e67632b 100644
> --- a/admin-cmds-legacy-interface.tex
> +++ b/admin-cmds-legacy-interface.tex
> @@ -187,7 +187,8 @@ \subsubsection{Legacy Interfaces}\label{sec:Basic Facilities of a Virtio Device
> by the device.
>
> Refer to the specific transport section for the definition of the
> -\field{data}.
> +\field{data}. For the PCI transport refer to section
> +\ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}.
>
> This command is currently only defined for the SR-IOV group type.
>
> diff --git a/conformance.tex b/conformance.tex
> index dc00e84..b3f2c92 100644
> --- a/conformance.tex
> +++ b/conformance.tex
> @@ -267,6 +267,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Legacy Interfaces: A Note on PCI Device Layout}
> \item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / Virtio Device Configuration Layout Detection / Legacy Interface: A Note on Device Layout Detection}
> \item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / Virtqueue Configuration / Legacy Interface: A Note on Virtqueue Configuration}
> +\item Section \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> \item Section \ref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}
> \item Section \ref{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Setting the Virtio Revision / Legacy Interfaces: A Note on Setting the Virtio Revision}
> \item Section \ref{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Configuring a Virtqueue / Legacy Interface: A Note on Configuring a Virtqueue}
> diff --git a/transport-pci-legacy-regs.tex b/transport-pci-legacy-regs.tex
> new file mode 100644
> index 0000000..ceea28c
> --- /dev/null
> +++ b/transport-pci-legacy-regs.tex
> @@ -0,0 +1,42 @@
> +\subsection{Legacy Interface: Group member device Configuration Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> +
> +The PCI owner device or the member device or both support driver notifications using
> +a notification region defined in \field{struct virtio_pci_legacy_notify_region}.
> +
> +In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
> +\field{region_data} is defined as following:
> +
> +\begin{lstlisting}
> +struct virtio_pci_legacy_notify_region {
> + u8 owner; /* When set to 1, notification region is of the owner device */
I propose we rename this to flags:
0x0 - end of list (driver should ignore following values until end of list)
0x1 - owner
0x2 - member
other values - reserved
and prescribe that driver ignores any reserved values.
basically we are following how the virtio capabilities work.
> + u8 bar; /* BAR of the member or owner device */
> + u8 padding[6];
> + le64 offset; /* Offset within bar. */
> +};
> +\end{lstlisting}
> +
> +The group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
> +capability.
> +
> +The group member device does not use PCI BAR0 in all the Virtio PCI capabilities
> +listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
Just drop this last one. How can they use it if there's no VF BAR0?
> +
> +\devicenormative{\subsubsection}{Legacy Interface: Group Member Device Legacy Configuration Region Access}{Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> +
> +When a PCI SR-IOV group owner device supports
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group owner device MUST
> +hardwire VF BAR0 to zero in the SR-IOV Extended capability and the group memberi
> +device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
> +
> +The group owner device or the group member device or both MAY support driver
> +notifications region.
> +
> +For the SR-IOV group type, the owner device supporting
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> +commands and its member device SHOULD follow the rules for the PCI Device ID,
> +Revision ID and Subsystem Device ID of the non-transitional devices documented in
> +section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Discovery}.
> diff --git a/transport-pci.tex b/transport-pci.tex
> index a5c6719..72c78f6 100644
> --- a/transport-pci.tex
> +++ b/transport-pci.tex
> @@ -1212,3 +1212,5 @@ \subsubsection{Driver Handling Interrupts}\label{sec:Virtio Transport Options /
> re-examine the configuration space to see what changed.
> \end{itemize}
> \end{itemize}
> +
> +\input{transport-pci-legacy-regs.tex}
> --
> 2.26.2
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 19:00 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 19:00 UTC (permalink / raw)
To: Parav Pandit
Cc: virtio-comment, cohuck, david.edmondson, virtio-dev, sburla,
jasowang, yishaih, maorg, shahafs
On Thu, Jul 06, 2023 at 07:17:14AM +0300, Parav Pandit wrote:
> This patch links how in a PCI transport a group owner can access group
> member (PCI VFs) legacy registers using a legacy registers access
> commands using administration virtqueue infrastructure.
>
> Additionally it extend the PCI notification capability through which a
> PCI VF device indicates to the driver which PCI BAR region to be used
> for driver notifications.
>
> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/167
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
> changelog:
> v9->v10:
> - addressed comments from Cornelia
> - fixed errors related to article
> - hardwire to hardwires
> - replaced various to all
> - added hardwire to zero
> v7->v8:
> - addressed comments from Michael
> - made bar offset 64-bit
> - prefix legacy specific structure with _legacy
> - moved generic normative from pci to generic section
> - added link to virtio pci capabilities when referring to bar 0
> - remove 'should' from generic description
> v6->v7:
> - addressed comments from Michael
> - removed driver normative about I/O BAR emulation as it does not
> make much sense for the spec
> - removed references to administration virtqueue
> - rewrote driver legacy region access without guest and hypervisor
> wording
> - added normative for notification region
> - added normative for PCI IDs for device which support legacy commands
> v5->v6:
> - aligned pci capability to 4B as required by PCI spec
> - added text for the PCI capability for the group member device
> v4->v5:
> - split pci transport and generic command section to new patch
> - removed multiple references to the VF
> - written the description of the command as generic with member
> and group device terminology
> - reflected many section names to remove VF
> v3->v4:
> - moved noted to the conformance section details in next patch
> - removed queue notify address query AQ command on Michael's suggestion,
> though it is fine. Instead replaced with extending virtio_pci_notify_cap
> to indicate that legacy queue notifications can be done on the
> notification location.
> - fixed spelling errors.
> - replaced administrative virtqueue to administration virtqueue
> - added queue notification capability register to indicate legacy q
> notification supported
> v2->v3:
> - adddressed Jason and Michael's comment to split single register
> access command to common config and device specific commands.
> - dropped the suggetion to introduce enable/disable command as
> admin command cap bit already covers it.
> v1->v2:
> - addressed comments from Michael
> - added theory of operation
> - grammar corrections
> - removed group fields description from individual commands as
> it is already present in generic section
> - added endianness normative for legacy device registers region
> - renamed the file to drop vf and add legacy prefix
>
> - added overview in commit log
> - renamed subsection to reflect command
> ---
> admin-cmds-legacy-interface.tex | 3 ++-
> conformance.tex | 1 +
> transport-pci-legacy-regs.tex | 42 +++++++++++++++++++++++++++++++++
> transport-pci.tex | 2 ++
> 4 files changed, 47 insertions(+), 1 deletion(-)
> create mode 100644 transport-pci-legacy-regs.tex
>
> diff --git a/admin-cmds-legacy-interface.tex b/admin-cmds-legacy-interface.tex
> index dd01c0a..e67632b 100644
> --- a/admin-cmds-legacy-interface.tex
> +++ b/admin-cmds-legacy-interface.tex
> @@ -187,7 +187,8 @@ \subsubsection{Legacy Interfaces}\label{sec:Basic Facilities of a Virtio Device
> by the device.
>
> Refer to the specific transport section for the definition of the
> -\field{data}.
> +\field{data}. For the PCI transport refer to section
> +\ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}.
>
> This command is currently only defined for the SR-IOV group type.
>
> diff --git a/conformance.tex b/conformance.tex
> index dc00e84..b3f2c92 100644
> --- a/conformance.tex
> +++ b/conformance.tex
> @@ -267,6 +267,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Legacy Interfaces: A Note on PCI Device Layout}
> \item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / Virtio Device Configuration Layout Detection / Legacy Interface: A Note on Device Layout Detection}
> \item Section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / Virtqueue Configuration / Legacy Interface: A Note on Virtqueue Configuration}
> +\item Section \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> \item Section \ref{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}
> \item Section \ref{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Setting the Virtio Revision / Legacy Interfaces: A Note on Setting the Virtio Revision}
> \item Section \ref{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Configuring a Virtqueue / Legacy Interface: A Note on Configuring a Virtqueue}
> diff --git a/transport-pci-legacy-regs.tex b/transport-pci-legacy-regs.tex
> new file mode 100644
> index 0000000..ceea28c
> --- /dev/null
> +++ b/transport-pci-legacy-regs.tex
> @@ -0,0 +1,42 @@
> +\subsection{Legacy Interface: Group member device Configuration Region Access}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> +
> +The PCI owner device or the member device or both support driver notifications using
> +a notification region defined in \field{struct virtio_pci_legacy_notify_region}.
> +
> +In \field{struct virtio_virtio_admin_cmd_legacy_notify_query_entry},
> +\field{region_data} is defined as following:
> +
> +\begin{lstlisting}
> +struct virtio_pci_legacy_notify_region {
> + u8 owner; /* When set to 1, notification region is of the owner device */
I propose we rename this to flags:
0x0 - end of list (driver should ignore following values until end of list)
0x1 - owner
0x2 - member
other values - reserved
and prescribe that driver ignores any reserved values.
basically we are following how the virtio capabilities work.
> + u8 bar; /* BAR of the member or owner device */
> + u8 padding[6];
> + le64 offset; /* Offset within bar. */
> +};
> +\end{lstlisting}
> +
> +The group owner device hardwires VF BAR0 to zero in the SR-IOV Extended
> +capability.
> +
> +The group member device does not use PCI BAR0 in all the Virtio PCI capabilities
> +listed in section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / Virtio Structure PCI Capabilities}.
Just drop this last one. How can they use it if there's no VF BAR0?
> +
> +\devicenormative{\subsubsection}{Legacy Interface: Group Member Device Legacy Configuration Region Access}{Virtio Transport Options / Virtio Over PCI Bus / Legacy Interface: Group Member Device Configuration Region Access}
> +
> +When a PCI SR-IOV group owner device supports
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE commands, the group owner device MUST
> +hardwire VF BAR0 to zero in the SR-IOV Extended capability and the group memberi
> +device MUST NOT use BAR0 in any of the Virtio Structure PCI Capabilities.
> +
> +The group owner device or the group member device or both MAY support driver
> +notifications region.
> +
> +For the SR-IOV group type, the owner device supporting
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE, VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_READ,
> +VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE and VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_QUERY
> +commands and its member device SHOULD follow the rules for the PCI Device ID,
> +Revision ID and Subsystem Device ID of the non-transitional devices documented in
> +section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Discovery}.
> diff --git a/transport-pci.tex b/transport-pci.tex
> index a5c6719..72c78f6 100644
> --- a/transport-pci.tex
> +++ b/transport-pci.tex
> @@ -1212,3 +1212,5 @@ \subsubsection{Driver Handling Interrupts}\label{sec:Virtio Transport Options /
> re-examine the configuration space to see what changed.
> \end{itemize}
> \end{itemize}
> +
> +\input{transport-pci-legacy-regs.tex}
> --
> 2.26.2
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 19:00 ` [virtio-comment] " Michael S. Tsirkin
@ 2023-07-06 19:07 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 19:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtio-comment, cohuck, david.edmondson, virtio-dev, sburla,
jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Michael S. Tsirkin
> Sent: Thursday, July 6, 2023 3:01 PM
> > +\begin{lstlisting}
> > +struct virtio_pci_legacy_notify_region {
> > + u8 owner; /* When set to 1, notification region is of the
> > +owner device */
>
> I propose we rename this to flags:
> 0x0 - end of list (driver should ignore following values until end of list)
> 0x1 - owner
> 0x2 - member
> other values - reserved
>
> and prescribe that driver ignores any reserved values.
>
> basically we are following how the virtio capabilities work.
>
Looks good. Will change it.
> > +The group owner device hardwires VF BAR0 to zero in the SR-IOV
> > +Extended capability.
> > +
> > +The group member device does not use PCI BAR0 in all the Virtio PCI
> > +capabilities listed in section \ref{sec:Virtio Transport Options / Virtio Over
> PCI Bus / Virtio Structure PCI Capabilities}.
>
> Just drop this last one. How can they use it if there's no VF BAR0?
>
Hardwaring BAR0 is in BAR area of the VF.
But virtio pci capabilities without this can still report bar 0 and virtio capabilities.
Ofcourse, it is a broken device.
But skipping this line imply that "because VF BAR0 is hardwired", this metadata in pci capability must not expose it.
Why not write it extra thing instead of implying it?
We already wrote few duplicate things to make reader life easier.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* RE: [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 19:07 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 19:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtio-comment, cohuck, david.edmondson, virtio-dev, sburla,
jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Michael S. Tsirkin
> Sent: Thursday, July 6, 2023 3:01 PM
> > +\begin{lstlisting}
> > +struct virtio_pci_legacy_notify_region {
> > + u8 owner; /* When set to 1, notification region is of the
> > +owner device */
>
> I propose we rename this to flags:
> 0x0 - end of list (driver should ignore following values until end of list)
> 0x1 - owner
> 0x2 - member
> other values - reserved
>
> and prescribe that driver ignores any reserved values.
>
> basically we are following how the virtio capabilities work.
>
Looks good. Will change it.
> > +The group owner device hardwires VF BAR0 to zero in the SR-IOV
> > +Extended capability.
> > +
> > +The group member device does not use PCI BAR0 in all the Virtio PCI
> > +capabilities listed in section \ref{sec:Virtio Transport Options / Virtio Over
> PCI Bus / Virtio Structure PCI Capabilities}.
>
> Just drop this last one. How can they use it if there's no VF BAR0?
>
Hardwaring BAR0 is in BAR area of the VF.
But virtio pci capabilities without this can still report bar 0 and virtio capabilities.
Ofcourse, it is a broken device.
But skipping this line imply that "because VF BAR0 is hardwired", this metadata in pci capability must not expose it.
Why not write it extra thing instead of implying it?
We already wrote few duplicate things to make reader life easier.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 19:00 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 19:42 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 19:42 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 07:00:22PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 2:57 PM
>
> > > I am just saying to keep things simple. Let driver choose any entry it wants to
> > use instead of device deciding on priority and hints etc.
> >
> > Let's say driver can support both types which to choose?
> Any entry that driver likes.
>
> > As the order is there anyway, why not just prescribe entries are used in order?
>
> I don't see any value in defining any order. It is an array of entries not a priority list.
I think we are losing out. For example I can see how
access through member would be preferable for ordering reasons.
However device might still allow access through PF for cases
where driver can't access VF.
But I don't see any configs where leaving this to the driver's
discretion is preferable. If you see one let me know.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 19:42 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 19:42 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 07:00:22PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 2:57 PM
>
> > > I am just saying to keep things simple. Let driver choose any entry it wants to
> > use instead of device deciding on priority and hints etc.
> >
> > Let's say driver can support both types which to choose?
> Any entry that driver likes.
>
> > As the order is there anyway, why not just prescribe entries are used in order?
>
> I don't see any value in defining any order. It is an array of entries not a priority list.
I think we are losing out. For example I can see how
access through member would be preferable for ordering reasons.
However device might still allow access through PF for cases
where driver can't access VF.
But I don't see any configs where leaving this to the driver's
discretion is preferable. If you see one let me know.
--
MST
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 19:07 ` Parav Pandit
@ 2023-07-06 19:59 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 19:59 UTC (permalink / raw)
To: Parav Pandit
Cc: virtio-comment, cohuck, david.edmondson, virtio-dev, sburla,
jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 07:07:42PM +0000, Parav Pandit wrote:
> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> > open.org> On Behalf Of Michael S. Tsirkin
> > Sent: Thursday, July 6, 2023 3:01 PM
>
> > > +\begin{lstlisting}
> > > +struct virtio_pci_legacy_notify_region {
> > > + u8 owner; /* When set to 1, notification region is of the
> > > +owner device */
> >
> > I propose we rename this to flags:
> > 0x0 - end of list (driver should ignore following values until end of list)
> > 0x1 - owner
> > 0x2 - member
> > other values - reserved
> >
>
> > and prescribe that driver ignores any reserved values.
> >
> > basically we are following how the virtio capabilities work.
> >
> Looks good. Will change it.
>
> > > +The group owner device hardwires VF BAR0 to zero in the SR-IOV
> > > +Extended capability.
> > > +
> > > +The group member device does not use PCI BAR0 in all the Virtio PCI
> > > +capabilities listed in section \ref{sec:Virtio Transport Options / Virtio Over
> > PCI Bus / Virtio Structure PCI Capabilities}.
> >
> > Just drop this last one. How can they use it if there's no VF BAR0?
> >
> Hardwaring BAR0 is in BAR area of the VF.
> But virtio pci capabilities without this can still report bar 0 and virtio capabilities.
How do they do this?
> Ofcourse, it is a broken device.
> But skipping this line imply that "because VF BAR0 is hardwired", this metadata in pci capability must not expose it.
>
> Why not write it extra thing instead of implying it?
> We already wrote few duplicate things to make reader life easier.
If you really want to go ahead, but prefix it with "In consequence" and
do not start a new paragraph, so reader knows it's not an extra
requirement.
So I started writing it using correct grammar and spec terminology:
In consequence, non of the group member devices has BAR0, and
in particular none of the virtio structure capabilities
of a member device has \field{bar} with the value of 0.
However, this actually is kind of wrong (and so is your text). Not all
caps have a RO bar value. virtio_pci_cfg_cap has bar that is RW by
driver. So if we are going this route we also need to explain that it's
true for all caps except virtio_pci_cfg_cap. And for virtio_pci_cfg_cap
driver is not allowed to write 0 there.
Frankly too much trouble but if you want to, keep trying.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 19:59 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 19:59 UTC (permalink / raw)
To: Parav Pandit
Cc: virtio-comment, cohuck, david.edmondson, virtio-dev, sburla,
jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 07:07:42PM +0000, Parav Pandit wrote:
> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> > open.org> On Behalf Of Michael S. Tsirkin
> > Sent: Thursday, July 6, 2023 3:01 PM
>
> > > +\begin{lstlisting}
> > > +struct virtio_pci_legacy_notify_region {
> > > + u8 owner; /* When set to 1, notification region is of the
> > > +owner device */
> >
> > I propose we rename this to flags:
> > 0x0 - end of list (driver should ignore following values until end of list)
> > 0x1 - owner
> > 0x2 - member
> > other values - reserved
> >
>
> > and prescribe that driver ignores any reserved values.
> >
> > basically we are following how the virtio capabilities work.
> >
> Looks good. Will change it.
>
> > > +The group owner device hardwires VF BAR0 to zero in the SR-IOV
> > > +Extended capability.
> > > +
> > > +The group member device does not use PCI BAR0 in all the Virtio PCI
> > > +capabilities listed in section \ref{sec:Virtio Transport Options / Virtio Over
> > PCI Bus / Virtio Structure PCI Capabilities}.
> >
> > Just drop this last one. How can they use it if there's no VF BAR0?
> >
> Hardwaring BAR0 is in BAR area of the VF.
> But virtio pci capabilities without this can still report bar 0 and virtio capabilities.
How do they do this?
> Ofcourse, it is a broken device.
> But skipping this line imply that "because VF BAR0 is hardwired", this metadata in pci capability must not expose it.
>
> Why not write it extra thing instead of implying it?
> We already wrote few duplicate things to make reader life easier.
If you really want to go ahead, but prefix it with "In consequence" and
do not start a new paragraph, so reader knows it's not an extra
requirement.
So I started writing it using correct grammar and spec terminology:
In consequence, non of the group member devices has BAR0, and
in particular none of the virtio structure capabilities
of a member device has \field{bar} with the value of 0.
However, this actually is kind of wrong (and so is your text). Not all
caps have a RO bar value. virtio_pci_cfg_cap has bar that is RW by
driver. So if we are going this route we also need to explain that it's
true for all caps except virtio_pci_cfg_cap. And for virtio_pci_cfg_cap
driver is not allowed to write 0 there.
Frankly too much trouble but if you want to, keep trying.
--
MST
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 19:42 ` [virtio-comment] " Michael S. Tsirkin
@ 2023-07-06 20:21 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 20:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 3:43 PM
> > > As the order is there anyway, why not just prescribe entries are used in
> order?
> >
> > I don't see any value in defining any order. It is an array of entries not a priority
> list.
>
> I think we are losing out. For example I can see how access through member
> would be preferable for ordering reasons.
> However device might still allow access through PF for cases where driver can't
> access VF.
>
So a driver can choose say I prefer order over accessibility over VF, so it choose PF.
Device doesn't have the knowledge anyway whether driver can/cannot access the VF.
So, device's preference vs driver's preference may be different.
> But I don't see any configs where leaving this to the driver's discretion is
> preferable. If you see one let me know.
In doesn't need to be config.
It is the environment that chooses which is preferred by the driver.
For example preference of accessibility over ordering.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 20:21 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 20:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 3:43 PM
> > > As the order is there anyway, why not just prescribe entries are used in
> order?
> >
> > I don't see any value in defining any order. It is an array of entries not a priority
> list.
>
> I think we are losing out. For example I can see how access through member
> would be preferable for ordering reasons.
> However device might still allow access through PF for cases where driver can't
> access VF.
>
So a driver can choose say I prefer order over accessibility over VF, so it choose PF.
Device doesn't have the knowledge anyway whether driver can/cannot access the VF.
So, device's preference vs driver's preference may be different.
> But I don't see any configs where leaving this to the driver's discretion is
> preferable. If you see one let me know.
In doesn't need to be config.
It is the environment that chooses which is preferred by the driver.
For example preference of accessibility over ordering.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 20:21 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 20:28 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 20:28 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 08:21:13PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 3:43 PM
>
> > > > As the order is there anyway, why not just prescribe entries are used in
> > order?
> > >
> > > I don't see any value in defining any order. It is an array of entries not a priority
> > list.
> >
> > I think we are losing out. For example I can see how access through member
> > would be preferable for ordering reasons.
> > However device might still allow access through PF for cases where driver can't
> > access VF.
> >
> So a driver can choose say I prefer order over accessibility over VF, so it choose PF.
> Device doesn't have the knowledge anyway whether driver can/cannot access the VF.
> So, device's preference vs driver's preference may be different.
The driver has a final decision. Let's make it a SHOULD and then if
driver knows best then it has the choice?
> > But I don't see any configs where leaving this to the driver's discretion is
> > preferable. If you see one let me know.
>
> In doesn't need to be config.
> It is the environment that chooses which is preferred by the driver.
> For example preference of accessibility over ordering.
what does accessibility mean exactly? I definitely see
OSes where owner driver can't access a member.
So in that case naturally driver will skip the
entry for member even if it's first. maybe there are
configs where member access is possible but is very slow
e.g. with lots of indirect function calls?
OK fine, but then it will be up to the driver to test and
make damn sure the benefits outweight the costs.
IOW it's a hint for the driver. If you like you can say
it explicitly even.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 20:28 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 20:28 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 08:21:13PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 3:43 PM
>
> > > > As the order is there anyway, why not just prescribe entries are used in
> > order?
> > >
> > > I don't see any value in defining any order. It is an array of entries not a priority
> > list.
> >
> > I think we are losing out. For example I can see how access through member
> > would be preferable for ordering reasons.
> > However device might still allow access through PF for cases where driver can't
> > access VF.
> >
> So a driver can choose say I prefer order over accessibility over VF, so it choose PF.
> Device doesn't have the knowledge anyway whether driver can/cannot access the VF.
> So, device's preference vs driver's preference may be different.
The driver has a final decision. Let's make it a SHOULD and then if
driver knows best then it has the choice?
> > But I don't see any configs where leaving this to the driver's discretion is
> > preferable. If you see one let me know.
>
> In doesn't need to be config.
> It is the environment that chooses which is preferred by the driver.
> For example preference of accessibility over ordering.
what does accessibility mean exactly? I definitely see
OSes where owner driver can't access a member.
So in that case naturally driver will skip the
entry for member even if it's first. maybe there are
configs where member access is possible but is very slow
e.g. with lots of indirect function calls?
OK fine, but then it will be up to the driver to test and
make damn sure the benefits outweight the costs.
IOW it's a hint for the driver. If you like you can say
it explicitly even.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* RE: [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 19:59 ` Michael S. Tsirkin
@ 2023-07-06 20:28 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 20:28 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtio-comment, cohuck, david.edmondson, virtio-dev, sburla,
jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 3:59 PM
> > Hardwaring BAR0 is in BAR area of the VF.
> > But virtio pci capabilities without this can still report bar 0 and virtio
> capabilities.
>
> How do they do this?
>
Device must not do it, but a broken device can report pci capabilities as garbage.
I will skip writing about it.
> > Ofcourse, it is a broken device.
> > But skipping this line imply that "because VF BAR0 is hardwired", this
> metadata in pci capability must not expose it.
> >
> > Why not write it extra thing instead of implying it?
> > We already wrote few duplicate things to make reader life easier.
>
> If you really want to go ahead, but prefix it with "In consequence" and do not
> start a new paragraph, so reader knows it's not an extra requirement.
>
> So I started writing it using correct grammar and spec terminology:
>
> In consequence, non of the group member devices has BAR0, and
> in particular none of the virtio structure capabilities
> of a member device has \field{bar} with the value of 0.
>
>
> However, this actually is kind of wrong (and so is your text). Not all caps have a
> RO bar value. virtio_pci_cfg_cap has bar that is RW by driver. So if we are going
> this route we also need to explain that it's true for all caps except
> virtio_pci_cfg_cap. And for virtio_pci_cfg_cap driver is not allowed to write 0
> there.
>
> Frankly too much trouble but if you want to, keep trying.
What I wrote still holds true because device wont have BAR0 and driver writing there is ignored.
But it is some weird broken device who expose PCI capabilities, so I am going to skip writing this.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 20:28 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 20:28 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtio-comment, cohuck, david.edmondson, virtio-dev, sburla,
jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 3:59 PM
> > Hardwaring BAR0 is in BAR area of the VF.
> > But virtio pci capabilities without this can still report bar 0 and virtio
> capabilities.
>
> How do they do this?
>
Device must not do it, but a broken device can report pci capabilities as garbage.
I will skip writing about it.
> > Ofcourse, it is a broken device.
> > But skipping this line imply that "because VF BAR0 is hardwired", this
> metadata in pci capability must not expose it.
> >
> > Why not write it extra thing instead of implying it?
> > We already wrote few duplicate things to make reader life easier.
>
> If you really want to go ahead, but prefix it with "In consequence" and do not
> start a new paragraph, so reader knows it's not an extra requirement.
>
> So I started writing it using correct grammar and spec terminology:
>
> In consequence, non of the group member devices has BAR0, and
> in particular none of the virtio structure capabilities
> of a member device has \field{bar} with the value of 0.
>
>
> However, this actually is kind of wrong (and so is your text). Not all caps have a
> RO bar value. virtio_pci_cfg_cap has bar that is RW by driver. So if we are going
> this route we also need to explain that it's true for all caps except
> virtio_pci_cfg_cap. And for virtio_pci_cfg_cap driver is not allowed to write 0
> there.
>
> Frankly too much trouble but if you want to, keep trying.
What I wrote still holds true because device wont have BAR0 and driver writing there is ignored.
But it is some weird broken device who expose PCI capabilities, so I am going to skip writing this.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 20:28 ` [virtio-dev] " Michael S. Tsirkin
@ 2023-07-06 20:35 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 20:35 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 4:29 PM
>
> The driver has a final decision. Let's make it a SHOULD and then if driver knows
> best then it has the choice?
>
As you said, the driver has the final say.
There is really no reason to complicate the spec for a narrow case where device cannot judge.
>
> > > But I don't see any configs where leaving this to the driver's
> > > discretion is preferable. If you see one let me know.
> >
> > In doesn't need to be config.
> > It is the environment that chooses which is preferred by the driver.
> > For example preference of accessibility over ordering.
>
>
> what does accessibility mean exactly? I definitely see OSes where owner driver
> can't access a member.
Accessibility = access a member
> So in that case naturally driver will skip the entry for member even if it's first.
> maybe there are configs where member access is possible but is very slow e.g.
> with lots of indirect function calls?
> OK fine, but then it will be up to the driver to test and make damn sure the
> benefits outweight the costs.
>
> IOW it's a hint for the driver. If you like you can say it explicitly even.
>
Device doesnt know anything about those indirect function calls, so device cannot hint about driver environment.
Can we please avoid this over engineering?
Interface has the doors open for driver to make wise decision depending on its environment.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 20:35 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 20:35 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 4:29 PM
>
> The driver has a final decision. Let's make it a SHOULD and then if driver knows
> best then it has the choice?
>
As you said, the driver has the final say.
There is really no reason to complicate the spec for a narrow case where device cannot judge.
>
> > > But I don't see any configs where leaving this to the driver's
> > > discretion is preferable. If you see one let me know.
> >
> > In doesn't need to be config.
> > It is the environment that chooses which is preferred by the driver.
> > For example preference of accessibility over ordering.
>
>
> what does accessibility mean exactly? I definitely see OSes where owner driver
> can't access a member.
Accessibility = access a member
> So in that case naturally driver will skip the entry for member even if it's first.
> maybe there are configs where member access is possible but is very slow e.g.
> with lots of indirect function calls?
> OK fine, but then it will be up to the driver to test and make damn sure the
> benefits outweight the costs.
>
> IOW it's a hint for the driver. If you like you can say it explicitly even.
>
Device doesnt know anything about those indirect function calls, so device cannot hint about driver environment.
Can we please avoid this over engineering?
Interface has the doors open for driver to make wise decision depending on its environment.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 20:35 ` [virtio-comment] " Parav Pandit
@ 2023-07-06 20:41 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 20:41 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 08:35:37PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 4:29 PM
> >
> > The driver has a final decision. Let's make it a SHOULD and then if driver knows
> > best then it has the choice?
> >
>
> As you said, the driver has the final say.
> There is really no reason to complicate the spec for a narrow case where device cannot judge.
>
> >
> > > > But I don't see any configs where leaving this to the driver's
> > > > discretion is preferable. If you see one let me know.
> > >
> > > In doesn't need to be config.
> > > It is the environment that chooses which is preferred by the driver.
> > > For example preference of accessibility over ordering.
> >
> >
> > what does accessibility mean exactly? I definitely see OSes where owner driver
> > can't access a member.
> Accessibility = access a member
>
> > So in that case naturally driver will skip the entry for member even if it's first.
> > maybe there are configs where member access is possible but is very slow e.g.
> > with lots of indirect function calls?
> > OK fine, but then it will be up to the driver to test and make damn sure the
> > benefits outweight the costs.
> >
> > IOW it's a hint for the driver. If you like you can say it explicitly even.
> >
> Device doesnt know anything about those indirect function calls, so device cannot hint about driver environment.
>
> Can we please avoid this over engineering?
> Interface has the doors open for driver to make wise decision depending on its environment.
what if driver can access both with the same ease? this is the
case that bothers me and I think it's practical since it will be
common on linux.
--
MST
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 20:41 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-06 20:41 UTC (permalink / raw)
To: Parav Pandit
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06, 2023 at 08:35:37PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, July 6, 2023 4:29 PM
> >
> > The driver has a final decision. Let's make it a SHOULD and then if driver knows
> > best then it has the choice?
> >
>
> As you said, the driver has the final say.
> There is really no reason to complicate the spec for a narrow case where device cannot judge.
>
> >
> > > > But I don't see any configs where leaving this to the driver's
> > > > discretion is preferable. If you see one let me know.
> > >
> > > In doesn't need to be config.
> > > It is the environment that chooses which is preferred by the driver.
> > > For example preference of accessibility over ordering.
> >
> >
> > what does accessibility mean exactly? I definitely see OSes where owner driver
> > can't access a member.
> Accessibility = access a member
>
> > So in that case naturally driver will skip the entry for member even if it's first.
> > maybe there are configs where member access is possible but is very slow e.g.
> > with lots of indirect function calls?
> > OK fine, but then it will be up to the driver to test and make damn sure the
> > benefits outweight the costs.
> >
> > IOW it's a hint for the driver. If you like you can say it explicitly even.
> >
> Device doesnt know anything about those indirect function calls, so device cannot hint about driver environment.
>
> Can we please avoid this over engineering?
> Interface has the doors open for driver to make wise decision depending on its environment.
what if driver can access both with the same ease? this is the
case that bothers me and I think it's practical since it will be
common on linux.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 20:41 ` [virtio-dev] " Michael S. Tsirkin
@ 2023-07-06 20:43 ` Parav Pandit
-1 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 20:43 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 4:42 PM
[..]
> > Can we please avoid this over engineering?
> > Interface has the doors open for driver to make wise decision depending on
> its environment.
>
> what if driver can access both with the same ease? this is the case that bothers
> me and I think it's practical since it will be common on linux.
Then Linux can say my preference is order, so it picks member.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-06 20:43 ` Parav Pandit
0 siblings, 0 replies; 78+ messages in thread
From: Parav Pandit @ 2023-07-06 20:43 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 4:42 PM
[..]
> > Can we please avoid this over engineering?
> > Interface has the doors open for driver to make wise decision depending on
> its environment.
>
> what if driver can access both with the same ease? this is the case that bothers
> me and I think it's practical since it will be common on linux.
Then Linux can say my preference is order, so it picks member.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-06 20:43 ` [virtio-comment] " Parav Pandit
@ 2023-07-07 8:12 ` Cornelia Huck
-1 siblings, 0 replies; 78+ messages in thread
From: Cornelia Huck @ 2023-07-07 8:12 UTC (permalink / raw)
To: Parav Pandit, Michael S. Tsirkin
Cc: virtio-comment, david.edmondson, virtio-dev, sburla, jasowang,
Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>> From: Michael S. Tsirkin <mst@redhat.com>
>> Sent: Thursday, July 6, 2023 4:42 PM
>
> [..]
>> > Can we please avoid this over engineering?
>> > Interface has the doors open for driver to make wise decision depending on
>> its environment.
>>
>> what if driver can access both with the same ease? this is the case that bothers
>> me and I think it's practical since it will be common on linux.
>
> Then Linux can say my preference is order, so it picks member.
Let's step back and consider what our goal is here: to provide a spec
that someone wanting to implement a driver can follow and end up with a
driver that works with devices that adhere to this spec.
I don't think expecting the driver to make "wise descisions" is helpful
for the person wanting to implement a driver. "Do this, and in case this
does not work in your environment, do that" seems much more helpful, and
still gives enough flexibility to cover different environments. In
short, make things simple for the consumer of the spec.
[Also, I notice that the discussion seems to get bogged down in tiny
details, fundamental statements, or a mixture of both. It might
sometimes be helpful to just step back, re-read the original proposal,
and only then answer. Otherwise, this leads to frustration for everyone
involved.]
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-07 8:12 ` Cornelia Huck
0 siblings, 0 replies; 78+ messages in thread
From: Cornelia Huck @ 2023-07-07 8:12 UTC (permalink / raw)
To: Parav Pandit, Michael S. Tsirkin
Cc: virtio-comment, david.edmondson, virtio-dev, sburla, jasowang,
Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Thu, Jul 06 2023, Parav Pandit <parav@nvidia.com> wrote:
>> From: Michael S. Tsirkin <mst@redhat.com>
>> Sent: Thursday, July 6, 2023 4:42 PM
>
> [..]
>> > Can we please avoid this over engineering?
>> > Interface has the doors open for driver to make wise decision depending on
>> its environment.
>>
>> what if driver can access both with the same ease? this is the case that bothers
>> me and I think it's practical since it will be common on linux.
>
> Then Linux can say my preference is order, so it picks member.
Let's step back and consider what our goal is here: to provide a spec
that someone wanting to implement a driver can follow and end up with a
driver that works with devices that adhere to this spec.
I don't think expecting the driver to make "wise descisions" is helpful
for the person wanting to implement a driver. "Do this, and in case this
does not work in your environment, do that" seems much more helpful, and
still gives enough flexibility to cover different environments. In
short, make things simple for the consumer of the spec.
[Also, I notice that the discussion seems to get bogged down in tiny
details, fundamental statements, or a mixture of both. It might
sometimes be helpful to just step back, re-read the original proposal,
and only then answer. Otherwise, this leads to frustration for everyone
involved.]
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* [virtio-dev] Re: [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
2023-07-07 8:12 ` [virtio-dev] " Cornelia Huck
@ 2023-07-07 8:32 ` Michael S. Tsirkin
-1 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-07 8:32 UTC (permalink / raw)
To: Cornelia Huck
Cc: Parav Pandit, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Fri, Jul 07, 2023 at 10:12:35AM +0200, Cornelia Huck wrote:
> [Also, I notice that the discussion seems to get bogged down in tiny
> details, fundamental statements, or a mixture of both. It might
> sometimes be helpful to just step back, re-read the original proposal,
> and only then answer. Otherwise, this leads to frustration for everyone
> involved.]
I feel in this instance we are actually good. All that's left is
small details that's why we are discussing them.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [virtio-comment] RE: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
@ 2023-07-07 8:32 ` Michael S. Tsirkin
0 siblings, 0 replies; 78+ messages in thread
From: Michael S. Tsirkin @ 2023-07-07 8:32 UTC (permalink / raw)
To: Cornelia Huck
Cc: Parav Pandit, virtio-comment, david.edmondson, virtio-dev,
sburla, jasowang, Yishai Hadas, Maor Gottlieb, Shahaf Shuler
On Fri, Jul 07, 2023 at 10:12:35AM +0200, Cornelia Huck wrote:
> [Also, I notice that the discussion seems to get bogged down in tiny
> details, fundamental statements, or a mixture of both. It might
> sometimes be helpful to just step back, re-read the original proposal,
> and only then answer. Otherwise, this leads to frustration for everyone
> involved.]
I feel in this instance we are actually good. All that's left is
small details that's why we are discussing them.
--
MST
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 78+ messages in thread
end of thread, other threads:[~2023-07-07 8:32 UTC | newest]
Thread overview: 78+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-06 4:17 [virtio-dev] [PATCH v10 0/4] admin: Access legacy registers using admin commands Parav Pandit
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
2023-07-06 4:17 ` [virtio-dev] [PATCH v10 1/4] admin: Split opcode table rows with a line Parav Pandit
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
2023-07-06 4:17 ` [virtio-dev] [PATCH v10 2/4] admin: Fix section numbering Parav Pandit
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
2023-07-06 13:39 ` [virtio-dev] " Cornelia Huck
2023-07-06 13:39 ` [virtio-comment] " Cornelia Huck
2023-07-06 4:17 ` [virtio-dev] [PATCH v10 3/4] admin: Add group member legacy register access commands Parav Pandit
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
2023-07-06 16:12 ` [virtio-dev] " Cornelia Huck
2023-07-06 16:12 ` [virtio-comment] " Cornelia Huck
2023-07-06 16:16 ` [virtio-dev] " Parav Pandit
2023-07-06 16:16 ` [virtio-comment] " Parav Pandit
2023-07-06 4:17 ` [virtio-dev] [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access Parav Pandit
2023-07-06 4:17 ` [virtio-comment] " Parav Pandit
2023-07-06 16:28 ` [virtio-dev] " Cornelia Huck
2023-07-06 16:28 ` [virtio-comment] " Cornelia Huck
2023-07-06 16:33 ` [virtio-dev] " Parav Pandit
2023-07-06 16:33 ` [virtio-comment] " Parav Pandit
2023-07-06 16:42 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 16:42 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 16:58 ` [virtio-dev] " Parav Pandit
2023-07-06 16:58 ` [virtio-comment] " Parav Pandit
2023-07-06 17:33 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 17:33 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 17:47 ` [virtio-dev] " Parav Pandit
2023-07-06 17:47 ` [virtio-comment] " Parav Pandit
2023-07-06 18:06 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 18:06 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 18:16 ` [virtio-dev] " Parav Pandit
2023-07-06 18:16 ` [virtio-comment] " Parav Pandit
2023-07-06 18:48 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 18:48 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 18:53 ` [virtio-dev] " Parav Pandit
2023-07-06 18:53 ` [virtio-comment] " Parav Pandit
2023-07-06 18:56 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 18:56 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 19:00 ` [virtio-dev] " Parav Pandit
2023-07-06 19:00 ` [virtio-comment] " Parav Pandit
2023-07-06 19:42 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 19:42 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 20:21 ` [virtio-dev] " Parav Pandit
2023-07-06 20:21 ` [virtio-comment] " Parav Pandit
2023-07-06 20:28 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 20:28 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 20:35 ` [virtio-dev] " Parav Pandit
2023-07-06 20:35 ` [virtio-comment] " Parav Pandit
2023-07-06 20:41 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 20:41 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 20:43 ` [virtio-dev] " Parav Pandit
2023-07-06 20:43 ` [virtio-comment] " Parav Pandit
2023-07-07 8:12 ` Cornelia Huck
2023-07-07 8:12 ` [virtio-dev] " Cornelia Huck
2023-07-07 8:32 ` Michael S. Tsirkin
2023-07-07 8:32 ` Michael S. Tsirkin
2023-07-06 17:38 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 17:38 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 16:47 ` [virtio-dev] " Cornelia Huck
2023-07-06 16:47 ` [virtio-comment] " Cornelia Huck
2023-07-06 16:52 ` [virtio-dev] " Parav Pandit
2023-07-06 16:52 ` [virtio-comment] " Parav Pandit
2023-07-06 16:39 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 16:39 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 16:45 ` [virtio-dev] " Parav Pandit
2023-07-06 16:45 ` [virtio-comment] " Parav Pandit
2023-07-06 16:50 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 16:50 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 16:54 ` [virtio-dev] " Parav Pandit
2023-07-06 16:54 ` [virtio-comment] " Parav Pandit
2023-07-06 19:00 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 19:00 ` [virtio-comment] " Michael S. Tsirkin
2023-07-06 19:07 ` [virtio-dev] " Parav Pandit
2023-07-06 19:07 ` Parav Pandit
2023-07-06 19:59 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 19:59 ` Michael S. Tsirkin
2023-07-06 20:28 ` Parav Pandit
2023-07-06 20:28 ` [virtio-dev] " Parav Pandit
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.