Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state

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

CC MST and Jason

On 9/18/2023 1:21 PM, Zhu, Lingshan wrote:
>
>
> On 9/18/2023 12:32 PM, Parav Pandit wrote:
>>
>>> From: Zhu, Lingshan <lingshan.zhu@intel.com>
>>> Sent: Monday, September 18, 2023 8:40 AM
>>>
>>> On 9/17/2023 1:32 PM, Parav Pandit wrote:
>>>>> From: virtio-dev@lists.oasis-open.org
>>>>> <virtio-dev@lists.oasis-open.org> On Behalf Of Zhu, Lingshan
>>>>> Sent: Friday, September 15, 2023 9:59 AM
>>>>>
>>>>> On 9/14/2023 7:14 PM, Michael S. Tsirkin wrote:
>>>>>> On Wed, Sep 06, 2023 at 04:16:32PM +0800, Zhu Lingshan wrote:
>>>>>>> This series introduces
>>>>>>> 1)a new SUSPEND bit in the device status Which is used to suspend
>>>>>>> the device, so that the device states and virtqueue states are
>>>>>>> stabilized.
>>>>>>>
>>>>>>> 2)virtqueue state and its accessor, to get and set last_avail_idx
>>>>>>> and last_used_idx of virtqueues.
>>>>>>>
>>>>>>> The main usecase of these new facilities is Live Migration.
>>>>>>>
>>>>>>> Future work: dirty page tracking and in-flight descriptors.
>>>>>>> This series addresses many comments from Jason, Stefan and Eugenio
>>>>>>> from RFC series.
>>>>>> Compared to Parav's patchset this is much less functional.
>>>>> we will add dirty page tracking and in-flight IO tracker in V2, then
>>>>> it will be a full featured LM solution.
>>>>>
>>>>> They are not in this series because we want this series to be 
>>>>> small and focus.
>>>>>> Assuming that one goes in, can't we add ability to submit admin
>>>>>> commands through MMIO on the device itself and be done with it?
>>>>> I am not sure, IMHO, if we use admin vq as back-ends for MMIO based
>>>>> live migration, then the issues in admin vq still exist, for example:
>>>>> 1)nested virtualization
>>>>> 2)bare-metal live migration
>>>>> 3)QOS
>>>>> 4)introduce more attacking surfaces.
>>>>>
>>>> #4 is just random without.
>>> I failed to process "random without".
>>>
>>> If you expect admin vq to perform live migration, it can certainly 
>>> be a side
>>> channel attacking surface, for example:
>>> a) a malicious SW can stop the device running
>>> b) a malicious SW can sniff guest memory by tracking guest dirty 
>>> pages, then
>>> speculate guest operations and stole secrets.
>> This is the mode when hypervisor is trusted.
> PF is not always owned by the hypervisor, right?
> And you don't pass-through the PF to any guests, right?
>> When hypervisor is untrusted, the CC model TDISP enabled device, TSM 
>> will delegate the tasks to the DSM.
> TDISP devices can not be migrated for now.
>>
>> For untrusted hypervisor, same set of attack surface is present with 
>> trap+emulation.
>> So both method score same. Hence its not relevant point for discussion.
> this is not hypervisor, Do you see any modern hypervisor have these 
> issues?
>
> This is admin vq for LM can be a side channel attacking surface.
>>
>>>> #3 There is no QoS issue with admin commands and queues. If you 
>>>> claim that
>>> then whole virtio spec based on the virtqueues is broken.
>>>> And it is certainly not the case.
>>> Please do not confuse the concepts and purposes of the data queues and
>>> admin vq.
>>>
>> I am not confused.
>> There is no guarantee that a register placed on the VF will be 
>> serviced by the device in exact same time regardless of VF count = 1 
>> or 4000.
>> Yet again not relevant comparison.
> please read my previous replies in other threads.
>>
>>> For data-queues, it can be slow without mq or rss, that means 
>>> performance
>>> overhead, but can work.
>> No, it does not work. The application failed because of jitter in the 
>> video and audio due to missing the latency budget.
>> A financial application is terminated due to timeouts and packet loss.
>>
>> Device migration is just another 3rd such applications.
>>
>> Its also same.
>> My last reply on this vague argument.
> I think the points are clear, and you already understand the points, 
> so no need to argue anymore
>>
>>> For admin vq, if it don't meet QOS requirements, it fails to migrate 
>>> guests.
>>>
>>> I have replied to the same question so many times, and this is the 
>>> last time.
>> I also replied many times that QoS argument is not valid anymore. 
>> Same can happen with registers writes.
>> Perf characteristics for 30+ devices is not in the virtio spec. It is 
>> implementation details.
> as replied many times, registers only serve the device itself and 
> registers are not DATA PATH,
> means the device don't transfer data through registers.
>


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