在 2021/7/13 下午8:28, Cornelia Huck 写道:
On Tue, Jul 13 2021, Jason Wang <[email protected]> wrote:
在 2021/7/13 下午7:31, Cornelia Huck 写道:
On Tue, Jul 13 2021, Jason Wang <[email protected]> wrote:
在 2021/7/13 下午4:19, Cornelia Huck 写道:
On Tue, Jul 13 2021, Jason Wang <[email protected]> wrote:
在 2021/7/12 下午5:57, Stefan Hajnoczi 写道:
When migrating a guest with many VIRTIO devices a busy waiting approach
extends downtime if implemented sequentially (stopping one device at a
time).
Well. You need some kinds of waiting for sure, the device/DMA needs
sometime to be stopped. The downtime is determined by a specific virtio
implementation which is hard to be restricted at the spec level. We can
clarify that the device must set the STOP bit in e.g 100ms.
I don't think we can introduce arbitrary upper bounds here. At most, we
can say that the device SHOULD try to set the STOP bit as early as
possible (and make use of the mechanism to expose in-flight buffers.)
Yes, that's my understanding.
If we want to avoid polling for the STOP bit, we need some kind of
notification mechanism, I guess. For ccw, I'd just use a channel
command to stop the device; completion of that channel program would
indicate that the device is done with the stop procedure.
A question, is interrupt used for such notification, or the VMM can
choose to poll for the completion?
You can poll for the subchannel to become status pending.
Not sure how
well that translates to other transports.
Actually, it's not necessarily a busy polling. VMM can schedule other
process in and recheck the bit periodically.
Or as you mentioned before, we can use some kind of interrupt but it
would be more complicated than the simple status bit. It's better to
introduce the interrupt only if the status bit doesn't fit.
At least for ccw, waiting for the status bit to be set also involves an
interrupt or polling (we use another channel program to retrieve the
status.) A dedicated channel command would actually be better, as the
interrupt/status pending would already inform us of success.
So it looks to me it doesn't conflict with this design: the device must
wait for the device to be stopped to signal the success of the ccw command?
Yes, the difference is mainly how that information can be extracted.
So I had a look at how reset is described for ccw:
"
In order to reset a device, a driver sends the CCW_CMD_VDEV_RESET command.
"
This implies something similar, that is the success of the command means
the success of the reset.
I wonder maybe I can remove the "re-read" from the basic facility and
let the transport to decide what to do.
- for PCI, if a registers is used, we need re-read
- for CCW, follow the current implication, re-read is not needed and we
can wait/poll for the success of the ccw command
- for admin virtqueue, it should be something similar to ccw, wait/poll
for the success of the admin virtqueue command
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
