> From: Zhu, Lingshan <lingshan....@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. > > > >>>> 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. > 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. > > > >>>>>> #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.
