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

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

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

For data-queues, it can be slow without mq or rss, that means 
performance overhead, but can work.
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.
> > And what's more, if we wants to implementing a new capability onbehalf of
> > admin vq, does the capability need to store at least one descriptor buffer, that is
> > the capability length should be at least the max_lengh_of_buffer?
> >
> > If that is not possible, do we need to implement extra fields like length and
> > remaining_length, then the device repeating update the cap data, and the
> > driver repeat reading, way to complex and introduce significant downtime.
> At least I do not understand. May be you can explain more?
Just try consider how a MMIO bar cap can fit to max_buffer_size.
> We observe less than 300 msec downtime using admin commands over admin queue in internal tests in virtio area.
still QOS