OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] [PATCH 5/5] virtio-pci: implement VIRTIO_F_QUEUE_STATE




On 9/12/2023 5:06 PM, Zhu, Lingshan wrote:


On 9/12/2023 3:53 PM, Parav Pandit wrote:
From: Zhu, Lingshan <lingshan.zhu@intel.com>
Sent: Tuesday, September 12, 2023 12:59 PM

On 9/12/2023 2:49 PM, Parav Pandit wrote:
From: Zhu, Lingshan <lingshan.zhu@intel.com>
Sent: Tuesday, September 12, 2023 12:08 PM

On 9/12/2023 1:51 PM, Parav Pandit wrote:
From: Zhu, Lingshan <lingshan.zhu@intel.com>
Sent: Tuesday, September 12, 2023 9:19 AM

On 9/11/2023 7:50 PM, Parav Pandit wrote:
From: Zhu, Lingshan <lingshan.zhu@intel.com>
Sent: Monday, September 11, 2023 3:03 PM By the way, do you see
anything we need to improve in this series?
Admin commands for passthrough devices of [1] is comprehensive
proposal
covering all the aspects.
To me [1] is superset work that covers all needed functionality
and downtime
aspects.
I plan to improve [1] with v1 this week by extending device
context and
addressing other review comments.
[1]
https://lists.oasis-open.org/archives/virtio-comment/202309/msg000
61
.h
tml
I am not sure, we have discussed a lot about the potential issues
in the treads. I guess we should resolve them first. E.g., nested use cases.
You are using nesting use case as the _only_ use case and attempt to
steer
using that.
Not right.

If you want to discuss, then lets have both the use cases, attempt
to converge
and if we can its really good.
If we cannot, both requirements should be handled differently.
Isn't nested a clear use case that should be supported?
Most users who care for running real applications and real performance, have
not asked for nesting.
It is not mandatory case; it may be required for some users.
I donât know who needs M level nesting and how cpu also support its
acceleration etc to run some reasonable workload.
Nested is a common use case and it is mandatory.
Maybe it is common case for the users you interact with, it is required for some complicated mode.
How many level of nesting 10, 2, 100?

I donât see a point of debating that "nesting is the only case and mediation is the only way" to do device migration.

As I repeatedly acknowledged,
We are open to converge on doing administration commands that can work for passthrough and nested way.

I just donât see how nested solution can work without any mediation, as everything you do touches device reset and FLR flow and it practically breaks the PCI specification with these side band registers and faking device reset and FLR when asked.
This is the primary reason; I am less inclined to go the in-band method.
Until now, no one technically explained how it can even work on question from yesterday.

And if there is one, please explain, I am very interested to learn, how is this done without hacks where device reset by guest _actually_ reset the underlying member device while the dirty page tracking is also ongoing.

So, my humble request is, try to work towards co-existing both the methods if possible, rather than doing either or mode.
If you want AQ used for LM, it should support nested anyway, don't break user logic.


This (my)series can support nested.
supplementary: As Jason ever pointed out: the two solution can co-exist for sure, I am implementing basic facilities, admin vq can free feel to reuse them like forwarding messages to them, and this can help support nested.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]