[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [PATCH V2 2/2] virtio: introduce STOP status bit
On Tue, Jul 13 2021, Jason Wang <jasowang@redhat.com> wrote: > å 2021/7/13 äå7:31, Cornelia Huck åé: >> On Tue, Jul 13 2021, Jason Wang <jasowang@redhat.com> wrote: >> >>> å 2021/7/13 äå4:19, Cornelia Huck åé: >>>> On Tue, Jul 13 2021, Jason Wang <jasowang@redhat.com> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]