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

Parav Pandit
2023-09-17T05:32:29Z

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

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

We observe less than 300 msec downtime using admin commands over admin queue in internal tests in virtio area.