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


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org