All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"david.edmondson@oracle.com" <david.edmondson@oracle.com>,
	"virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"sburla@marvell.com" <sburla@marvell.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	Yishai Hadas <yishaih@nvidia.com>,
	Maor Gottlieb <maorg@nvidia.com>,
	Shahaf Shuler <shahafs@nvidia.com>
Subject: [virtio-comment] Re: [virtio-dev] Re: [PATCH v6 4/4] transport-pci: Introduce group legacy group member config region access
Date: Mon, 19 Jun 2023 13:46:12 -0400	[thread overview]
Message-ID: <20230619133754-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB5481D7DD7654CF3B18939956DC5FA@PH0PR12MB5481.namprd12.prod.outlook.com>

On Mon, Jun 19, 2023 at 05:35:04PM +0000, Parav Pandit wrote:
> 
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Monday, June 19, 2023 1:26 PM
> 
> > > > Also these devices will use non-transitional ID but they in fact do
> > > > have a legacy interface so using this definition they are
> > > > transitional devices. Maybe we need to add when we describe the
> > > > device ID text like "non transitional devices and transitional devices utilizing
> > commands XYZ" ...?
> > >
> > > Transitional device has specific meaning, I am not sure we should muddy it.
> > 
> > 
> > 
> > To simplify transition from these earlier draft interfaces, a device MAY
> > implement:
> > 
> > \begin{description}
> > \item[Transitional Device]
> >         a device supporting both drivers conforming to this
> >         specification, and allowing legacy drivers.
> > \end{description}
> > 
> > 
> > I agree it can be read this way. The issue is a lot of text in the spec just assumes
> > that "has legacy interface == transitional device".
> > 
> > 
> > 
> > For example:
> > When using the legacy interface the driver MAY access the device-specific
> > configuration region using any width accesses, and a transitional device MUST
> > present driver with the same results as when accessed using the ``natural''
> > access method (i.e.
> > 32-bit accesses for 32-bit fields, etc).
> > 
> > 
> > If we break the assumption we need to audit the spec for this
> > assumption and again, I really would rather not.
> 
> We are not breaking the assumption. Above listed requirement is already captured in the legacy interface conformance section.
> So I am not sure what extra to write here.
>  

Hmm not sure what's unclear.  I can try to explain the issue again.

These devices have a legacy interface yes?
So they should be transitional to avoid breaking assumption.


But they are not *exactly*
in that they don't have a transitional device ID.

At least the device id section needs extra text
then to explain this?

Or do you just want to make them have transitional ID?


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


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"david.edmondson@oracle.com" <david.edmondson@oracle.com>,
	"virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"sburla@marvell.com" <sburla@marvell.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	Yishai Hadas <yishaih@nvidia.com>,
	Maor Gottlieb <maorg@nvidia.com>,
	Shahaf Shuler <shahafs@nvidia.com>
Subject: Re: [virtio-dev] Re: [PATCH v6 4/4] transport-pci: Introduce group legacy group member config region access
Date: Mon, 19 Jun 2023 13:46:12 -0400	[thread overview]
Message-ID: <20230619133754-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB5481D7DD7654CF3B18939956DC5FA@PH0PR12MB5481.namprd12.prod.outlook.com>

On Mon, Jun 19, 2023 at 05:35:04PM +0000, Parav Pandit wrote:
> 
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Monday, June 19, 2023 1:26 PM
> 
> > > > Also these devices will use non-transitional ID but they in fact do
> > > > have a legacy interface so using this definition they are
> > > > transitional devices. Maybe we need to add when we describe the
> > > > device ID text like "non transitional devices and transitional devices utilizing
> > commands XYZ" ...?
> > >
> > > Transitional device has specific meaning, I am not sure we should muddy it.
> > 
> > 
> > 
> > To simplify transition from these earlier draft interfaces, a device MAY
> > implement:
> > 
> > \begin{description}
> > \item[Transitional Device]
> >         a device supporting both drivers conforming to this
> >         specification, and allowing legacy drivers.
> > \end{description}
> > 
> > 
> > I agree it can be read this way. The issue is a lot of text in the spec just assumes
> > that "has legacy interface == transitional device".
> > 
> > 
> > 
> > For example:
> > When using the legacy interface the driver MAY access the device-specific
> > configuration region using any width accesses, and a transitional device MUST
> > present driver with the same results as when accessed using the ``natural''
> > access method (i.e.
> > 32-bit accesses for 32-bit fields, etc).
> > 
> > 
> > If we break the assumption we need to audit the spec for this
> > assumption and again, I really would rather not.
> 
> We are not breaking the assumption. Above listed requirement is already captured in the legacy interface conformance section.
> So I am not sure what extra to write here.
>  

Hmm not sure what's unclear.  I can try to explain the issue again.

These devices have a legacy interface yes?
So they should be transitional to avoid breaking assumption.


But they are not *exactly*
in that they don't have a transitional device ID.

At least the device id section needs extra text
then to explain this?

Or do you just want to make them have transitional ID?


-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2023-06-19 17:46 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-13 17:30 [virtio-comment] [PATCH v6 0/4] admin: Introduce legacy registers access using AQ Parav Pandit
2023-06-13 17:30 ` [virtio-dev] " Parav Pandit
2023-06-13 17:30 ` [virtio-comment] [PATCH v6 1/4] admin: Split opcode table rows with a line Parav Pandit
2023-06-13 17:30   ` [virtio-dev] " Parav Pandit
2023-06-13 17:30 ` [virtio-comment] [PATCH v6 2/4] admin: Fix section numbering Parav Pandit
2023-06-13 17:30   ` [virtio-dev] " Parav Pandit
2023-06-13 17:30 ` [virtio-comment] [PATCH v6 3/4] admin: Add group member legacy register access commands Parav Pandit
2023-06-13 17:30   ` [virtio-dev] " Parav Pandit
2023-06-19 16:20   ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 16:20     ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 16:29     ` [virtio-comment] " Parav Pandit
2023-06-19 16:29       ` [virtio-dev] " Parav Pandit
2023-06-19 16:40       ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 16:40         ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 16:45         ` [virtio-comment] " Parav Pandit
2023-06-19 16:45           ` [virtio-dev] " Parav Pandit
2023-06-19 17:10           ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 17:10             ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 17:21             ` [virtio-comment] " Parav Pandit
2023-06-19 17:21               ` Parav Pandit
2023-06-19 17:33               ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 17:33                 ` Michael S. Tsirkin
2023-06-19 17:38                 ` [virtio-comment] " Parav Pandit
2023-06-19 17:38                   ` Parav Pandit
2023-06-13 17:30 ` [virtio-comment] [PATCH v6 4/4] transport-pci: Introduce group legacy group member config region access Parav Pandit
2023-06-13 17:30   ` [virtio-dev] " Parav Pandit
2023-06-19 16:16   ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 16:16     ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 21:07     ` [virtio-comment] " Parav Pandit
2023-06-19 21:07       ` [virtio-dev] " Parav Pandit
2023-06-21 20:05       ` [virtio-comment] " Michael S. Tsirkin
2023-06-21 20:05         ` [virtio-dev] " Michael S. Tsirkin
2023-06-21 20:22         ` Parav Pandit
2023-06-21 20:22           ` [virtio-dev] " Parav Pandit
2023-06-21 20:31           ` Michael S. Tsirkin
2023-06-21 20:31             ` [virtio-dev] " Michael S. Tsirkin
2023-06-21 20:43             ` Parav Pandit
2023-06-21 20:43               ` [virtio-dev] " Parav Pandit
2023-06-19 16:37   ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 16:37     ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 16:39     ` [virtio-comment] " Parav Pandit
2023-06-19 16:39       ` [virtio-dev] " Parav Pandit
2023-06-19 17:19       ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 17:19         ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 17:26         ` [virtio-comment] " Parav Pandit
2023-06-19 17:26           ` [virtio-dev] " Parav Pandit
2023-06-19 17:37           ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 17:37             ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 17:45             ` [virtio-comment] " Parav Pandit
2023-06-19 17:45               ` [virtio-dev] " Parav Pandit
2023-06-19 17:57               ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 17:57                 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 18:07                 ` [virtio-comment] " Parav Pandit
2023-06-19 18:07                   ` [virtio-dev] " Parav Pandit
2023-06-20 14:12                   ` [virtio-comment] " Parav Pandit
2023-06-20 14:12                     ` [virtio-dev] " Parav Pandit
2023-06-21 15:50                     ` [virtio-comment] " Parav Pandit
2023-06-21 15:50                       ` [virtio-dev] " Parav Pandit
2023-06-21 15:56                       ` [virtio-comment] " Michael S. Tsirkin
2023-06-21 15:56                         ` [virtio-dev] " Michael S. Tsirkin
2023-06-21 16:01                         ` [virtio-comment] " Parav Pandit
2023-06-21 16:01                           ` [virtio-dev] " Parav Pandit
2023-06-21 19:43                           ` [virtio-comment] " Michael S. Tsirkin
2023-06-21 19:43                             ` [virtio-dev] " Michael S. Tsirkin
2023-06-21 20:04                             ` Parav Pandit
2023-06-21 20:04                               ` [virtio-dev] " Parav Pandit
2023-06-21 20:08                               ` Michael S. Tsirkin
2023-06-21 20:08                                 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 18:00               ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 18:00                 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 18:12                 ` [virtio-comment] " Parav Pandit
2023-06-19 18:12                   ` [virtio-dev] " Parav Pandit
2023-06-21 19:47                   ` [virtio-comment] " Michael S. Tsirkin
2023-06-21 19:47                     ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 17:04   ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 17:04     ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 17:11     ` [virtio-comment] " Parav Pandit
2023-06-19 17:11       ` Parav Pandit
2023-06-19 17:26       ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 17:26         ` Michael S. Tsirkin
2023-06-19 17:35         ` [virtio-comment] " Parav Pandit
2023-06-19 17:35           ` Parav Pandit
2023-06-19 17:46           ` Michael S. Tsirkin [this message]
2023-06-19 17:46             ` Michael S. Tsirkin
2023-06-20  0:14             ` [virtio-comment] " Parav Pandit
2023-06-20  0:14               ` Parav Pandit
2023-06-20 10:21               ` [virtio-comment] " Michael S. Tsirkin
2023-06-20 10:21                 ` Michael S. Tsirkin
2023-06-21  1:09                 ` [virtio-comment] " Parav Pandit
2023-06-21  1:09                   ` Parav Pandit
2023-06-21  5:05                   ` [virtio-comment] " Michael S. Tsirkin
2023-06-21  5:05                     ` Michael S. Tsirkin
2023-06-19 12:38 ` [virtio-comment] RE: [PATCH v6 0/4] admin: Introduce legacy registers access using AQ Parav Pandit
2023-06-19 12:38   ` [virtio-dev] " Parav Pandit
2023-06-19 15:18   ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 15:18     ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 15:58     ` [virtio-comment] " Parav Pandit
2023-06-19 15:58       ` [virtio-dev] " Parav Pandit
2023-06-19 16:28 ` [virtio-comment] " Michael S. Tsirkin
2023-06-19 16:28   ` [virtio-dev] " Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230619133754-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=david.edmondson@oracle.com \
    --cc=jasowang@redhat.com \
    --cc=maorg@nvidia.com \
    --cc=parav@nvidia.com \
    --cc=sburla@marvell.com \
    --cc=shahafs@nvidia.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=yishaih@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is 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.