From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Jason Wang <jasowang@redhat.com>,
"virtio@lists.oasis-open.org" <virtio@lists.oasis-open.org>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
Shahaf Shuler <shahafs@nvidia.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
"hengqi@linux.alibaba.com" <hengqi@linux.alibaba.com>
Subject: [virtio-comment] Re: [virtio] RE: [virtio-comment] proposal: use admin command (and aq) of the device to query config space
Date: Wed, 2 Aug 2023 07:39:12 -0400 [thread overview]
Message-ID: <20230802073700-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <DM8PR12MB548071770075800FD9020D27DC0BA@DM8PR12MB5480.namprd12.prod.outlook.com>
On Wed, Aug 02, 2023 at 11:29:53AM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Wednesday, August 2, 2023 4:56 PM
> >
> > On Wed, Aug 02, 2023 at 09:57:47AM +0000, Parav Pandit wrote:
> > > > If you care about admin
> > > > virtqueue then device configuration space is not the only thing that
> > > > can be "ever growing", common_cfg is another one.
> > > The idea is to do minimal bootstrap work from the common config space and
> > switch to the queue.
> > > So common config shouldn’t be growing either other than minimal bootstrap
> > functionality.
> > > Hence, common config also to be available via dma command.
> >
> > That is more like a new transport. I thought this proposal is focusing on device
> > specific config - let's get a handle on that first?
> > "common config" is a pci transport specific thing.
>
> Sure, device config is the real pain point we are trying to solve first.
>
> Using cvq for those devices who has it seems the most optimal approach.
> If we liberate ourselves from single monolithic config space structure and move to query device capabilities, resources, configuration, at functionality level, life is lot easier.
> What are your thoughts?
Splitting transport and device config is exactly what I'm talking about.
I agree transport should probably be split further -
it only made sense for legacy so we don't need to spend
specification effort on legacy.
splitting device config would require changes to all devices -
I don't see how it's worth the effort.
--
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/
next prev parent reply other threads:[~2023-08-02 11:39 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 7:09 [virtio-comment] proposal: use admin command (and aq) of the device to query config space Parav Pandit
2023-08-02 4:20 ` [virtio-comment] " Michael S. Tsirkin
2023-08-02 4:33 ` [virtio-comment] " Parav Pandit
2023-08-02 8:45 ` [virtio-comment] " Zhu, Lingshan
2023-08-02 8:59 ` [virtio-comment] " Parav Pandit
2023-08-02 9:40 ` [virtio-comment] " Zhu, Lingshan
2023-08-02 10:00 ` [virtio-comment] " Parav Pandit
2023-08-02 11:35 ` [virtio-comment] " Michael S. Tsirkin
2023-08-02 11:51 ` [virtio-comment] " Parav Pandit
2023-08-02 11:53 ` [virtio-comment] " Michael S. Tsirkin
2023-08-02 11:58 ` [virtio-comment] " Parav Pandit
2023-08-02 12:10 ` [virtio-comment] " Michael S. Tsirkin
2023-08-02 8:53 ` [virtio-comment] " Jason Wang
2023-08-02 9:07 ` Parav Pandit
2023-08-02 9:32 ` [virtio-comment] Re: [virtio] " Jason Wang
2023-08-02 9:57 ` [virtio-comment] " Parav Pandit
2023-08-02 11:25 ` [virtio-comment] " Michael S. Tsirkin
2023-08-02 11:29 ` [virtio-comment] " Parav Pandit
2023-08-02 11:39 ` Michael S. Tsirkin [this message]
2023-08-02 11:44 ` [virtio-comment] " Parav Pandit
2023-08-02 11:50 ` Michael S. Tsirkin
2023-08-02 11:56 ` Parav Pandit
2023-08-02 12:09 ` Michael S. Tsirkin
2023-08-03 2:55 ` Jason Wang
2023-08-03 10:13 ` [virtio-comment] " Parav Pandit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230802073700-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=parav@nvidia.com \
--cc=shahafs@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.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.