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

[Parav Pandit <parav@nvidia.com>]

> 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.
When hypervisor is untrusted, the CC model TDISP enabled device, TSM will delegate the tasks to the DSM.

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.

> > #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.

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

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