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.