[virtio-comment] Re: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, May 24, 2023 at 06:57:30PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Wednesday, May 24, 2023 1:57 AM
> 
> 
> > I am frankly lost at this point, this thread is too big.
> > 
> > So where do you want to go for this project?  I would like something specific,
> > email threads are growing too big.
> > I think the reason is that there is actually a host of small related subprojects. So
> > when you propose just this small feature, everyone jumps in with their own pet
> > project proposing addressing that too.
> > 
> > For example:
> > - SIOV guys were adding transport over VQ. It would seem that
> >   can include support for legacy.
> Yes. SIOV can support legacy and modern emulation.
> We need to have the SIOV devices without this emulation support so that they natively good.
> 
> > - For migration we need ability to report member events to owner.
> Which events you have in mind?

memory faults/dirtying for example.

> The AQ is design to carry the migration of the VFs and would be controlled via the AQ so it knows whats going on.
> 
> >   It would seem that can be used to support INT#x.
> > - Ability to stick capabilities in extended config space
> >   is a good idea, for a variety of reasons.
> > 
> > and so on.  Understandably frustrating, and it is easy to go overboard with
> > generality.
> > 
> > If you feel your path for progress is clear, that's good.
> The path seems clear to me for supporting legacy registers access for the VFs and future SIOV.
> Let's conclude it in other thread we are discussing of patch 1/2.
> 
> > if not, here are ideas for getting this unstuck:
> > - start a TODO.md file with a list of things we need to address,
> >   and for each one a list of options
> > - everyone will add to this file then we get a higher level
> >   picture and can discuss "this will be addressed by A, that by B"
> This is certainly present in my personal todo list to discuss, I am happy to maintain in the public virtio doc at
> https://github.com/oasis-tcs/virtio-docs/
> 
> > - have a chat at the upstream developers meeting (May 31)
> >   so far it's about vdpa blk
> > - anyone coming to the kvm forum to have a chat there?
> > 
> > Hope this helps.
> Definitely a good suggestion.
> I will send PR for virtio-docs to maintain our TODO list.

Hmm. This is just a dumping ground then.  Fine by me, but what I had in
mind is a common list of known problems to address by TC as a whole.
If you want that we want patches on list and discussion, maybe even
voting.


> Since some of the discussions are ongoing basis if we can meet monthly
> on more practically on need basis, it will help to make progress
> faster.

That meeting is byweekly actually I think.

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