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
next prev parent reply other threads:[~2023-06-19 17:46 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 17:30 [virtio-dev] [PATCH v6 0/4] admin: Introduce legacy registers access using AQ Parav Pandit
2023-06-13 17:30 ` [virtio-dev] [PATCH v6 1/4] admin: Split opcode table rows with a line Parav Pandit
2023-06-13 17:30 ` [virtio-dev] [PATCH v6 2/4] admin: Fix section numbering Parav Pandit
2023-06-13 17:30 ` [virtio-dev] [PATCH v6 3/4] admin: Add group member legacy register access commands Parav Pandit
2023-06-19 16:20 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 16:29 ` [virtio-dev] " Parav Pandit
2023-06-19 16:40 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 16:45 ` [virtio-dev] " Parav Pandit
2023-06-19 17:10 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 17:21 ` Parav Pandit
2023-06-19 17:33 ` Michael S. Tsirkin
2023-06-19 17:38 ` Parav Pandit
2023-06-13 17:30 ` [virtio-dev] [PATCH v6 4/4] transport-pci: Introduce group legacy group member config region access Parav Pandit
2023-06-19 16:16 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 21:07 ` [virtio-dev] " Parav Pandit
2023-06-21 20:05 ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-06-21 20:22 ` [virtio-dev] " Parav Pandit
2023-06-21 20:31 ` [virtio-dev] " Michael S. Tsirkin
2023-06-21 20:43 ` [virtio-dev] " Parav Pandit
2023-06-19 16:37 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 16:39 ` [virtio-dev] " Parav Pandit
2023-06-19 17:19 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 17:26 ` [virtio-dev] " Parav Pandit
2023-06-19 17:37 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 17:45 ` [virtio-dev] " Parav Pandit
2023-06-19 17:57 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 18:07 ` [virtio-dev] " Parav Pandit
2023-06-20 14:12 ` Parav Pandit
2023-06-21 15:50 ` Parav Pandit
2023-06-21 15:56 ` [virtio-dev] " Michael S. Tsirkin
2023-06-21 16:01 ` [virtio-dev] " Parav Pandit
2023-06-21 19:43 ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-06-21 20:04 ` [virtio-dev] " Parav Pandit
2023-06-21 20:08 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 18:00 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 18:12 ` [virtio-dev] " Parav Pandit
2023-06-21 19:47 ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-06-19 17:04 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 17:11 ` Parav Pandit
2023-06-19 17:26 ` Michael S. Tsirkin
2023-06-19 17:35 ` Parav Pandit
2023-06-19 17:46 ` Michael S. Tsirkin [this message]
2023-06-20 0:14 ` Parav Pandit
2023-06-20 10:21 ` Michael S. Tsirkin
2023-06-21 1:09 ` Parav Pandit
2023-06-21 5:05 ` Michael S. Tsirkin
2023-06-19 12:38 ` [virtio-dev] RE: [PATCH v6 0/4] admin: Introduce legacy registers access using AQ Parav Pandit
2023-06-19 15:18 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 15:58 ` [virtio-dev] " Parav Pandit
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox