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

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

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.


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