[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio] RE: [virtio-comment] Re: [virtio] Re: [PATCH v10 04/10] admin: introduce virtio admin virtqueues
On Wed, Mar 08, 2023 at 01:17:44PM +0800, Jason Wang wrote: > On Wed, Mar 8, 2023 at 3:09âAM Parav Pandit <parav@nvidia.com> wrote: > > > > > > > > > From: Stefan Hajnoczi <stefanha@redhat.com> > > > Sent: Tuesday, March 7, 2023 2:04 PM > > > > > An alternative is unconditional out-of-order completion, where there are no > > > per-command ordering rules. The driver must wait for a command to complete > > > if it relies on the results of that command for its next command. I like this > > > approach because it's less complex in the spec and for device implementers, > > > while the burden on the driver implementer is still reasonable. > > +1. > > Note that this is the way current ctrl virtqueue works. > > > This has best of both. > > 1. Command ordering knowledge and hence the decision left to the one which issues them. (driver). > > 2. Ability to execute multiple unrelated commands using a single AQ. > > 3. stateless device in AQ command execution > > Does this mean if we want to migrate AQ (not use AQ to migrate), we > need to wait for the AQ command to be completed? It depends. Today, if the AQ is emulated by the VMM then it might be possible to migrate while there is a command in-flight. If the AQ is handled by the device then no because VIRTIO currently does not support device state migration. In the future, device state migration will probably be added to vhost-user and vDPA. In that case a device can migrate in-flight AQ activity - assuming it's possible to pause it, serialize state, deserialize it, and resume it. Otherwise it's still necessary to wait. To be clear, I'm just taking about AQ commands that are currently in the process of executing. Commands that are in the virtqueue but have not yet been started by the device can be easily migrated using the existing virtqueue migration infrastructure. Stefan
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]