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

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

On 9/18/2023 2:54 PM, Parav Pandit wrote:
>> From: Zhu, Lingshan <lingshan.zhu@intel.com>
>> Sent: Monday, September 18, 2023 12:19 PM
>
>> so admin vq based LM solution can be a side channel attacking surface
> It will be part of the DSM whenever it will be used in future.
> Hence, it is not attack surface.
I am not sure, why we have to trust the PF?
This is out of virtio scope anyway.

I have explained many times how it can be a attack surface, and examples.

What happen if malicious SW dump guest memory by admin vq dirty page
tracking feature?
>
>>>>>> 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.
>>> It is not.
>>> Hypervisor is trusted entity.
>>> For untrusted hypervisor the TDISP is unified solution build by the various
>> industry bodies including DMTF, PCI for last few years.
>>> We want to utilize that.
>> first, TDISP is out of virtio spec.
> Sure, hence, untrusted hypervisor are out of scope.
> Otherwise, trap+emulation is equally dead which relies on the hypervisor to do things.
so lets focus on LM topic, other than confidential computing.
>
>> second, TDISP devices can not be migrated for now third, admin vq can be an
>> side channel attacking surface as explained above.
> When TDISP are not used, hypervisor is trusted entity, period.
> And hence, it cannot be considered attack surface.
> An hypervisor can even disable SR-IOV.
if SRIOV is disabled, so you are migrating PF?
A PF certainly can not migrate itself by its own admin vq.

again, TDISP is out of spec and TDISP devices are not
migratable.
>
>>>>>>>> #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.
>>> It does not answer.
>>> The claim that somehow a polling register ensures downtime guarantee for
>> scale of thousands of member devices is some specific device implementation
>> without explanation.
>> the registers and the LM facilities are per-device.
>>>>>>> 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
>>> Yes, I am clear from long time, nor AQ nor no register, RSS queues, none
>> cannot guarantee any performance characteristics.
>>> It is pretty clear to me.
>>> Any performance guarantees are explicitly requested when desired.
>>>
>>>>>>> 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.
>>> It does not matter data path or control path, the fact is it downtime assurance
>> cannot be guaranteed by register interface design, it is the implementation
>> details.
>>> And so does for admin commands and/or AQ.
>> the registers do not perform any data transitions, e.g., we don't migrate dirty
>> pages through registers.
>> But you do these by admin vq
> So what?
> Just because data transfer is not done, it does not mean that thousands of polling register writes complete in stipulated time.
1) again, they are per-device facilities
2) we use very few registers, even status byte does not require polling, 
just re-read with delay.

Please refer to the code for setting FEATURES_OK.



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