On Thu, 2018-11-15 at 11:38 +0000, Julien Grall wrote: > On 11/15/18 11:10 AM, Mirela Simonovic wrote: > I don't think we are discussing the same thing. The discussion was > around other vCPUs, not the vCPU calling SYSTEM_SUSPEND. > > Most likely in the future, we would want to allow the toolstack to > request resuming the domain. This can be considered as an event. > > > Given the assumption, my understanding is that Xen itself will not > > unblock vCPU, except due to an interrupt targeted to the guest. > > Am I missing something? An example would be appreciated. > > At least on Arm, the current semantics of vcpu_block/vcpu_unblock is > to > block until you receive an events. > > I don't much want to restrict the definition of events to only > interrupts. To clarify my point, if you want to wake-up for any > events > then fine. > So, I certainly lack deep knowledge of PSCI, as well as other aspects of how this suspend/resume logic will work, but just to clarify on this.
vcpu_unblock() may indeed be called from a number of places, but it actually wakes-up the vcpu _iff_ the vcpu is runnable. If it is not --e.g., because pause_count is not zero, or any vcpu or domain pause_flags are set-- the vcpu stays blocked (check the implementation of vcpu_wake() and of vcpu_runnable()). So, it looks to me that what you want is to be sure that when an event arrives, but the vcpus need to remain suspended, vcpu_runnable() returns false for them. OTOH, when the events that you want to wake them up arrives, you want it to return true. Whether that is better done by using pause_count (plus some other flag, as Stefano is saying) or with either an existing or new vcpu or domain pause flag, I don't know, but it looks like it could work to me. Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel