Re: [PATCH 0/6] KVM: arm64: Implement PSCI SYSTEM_SUSPEND support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Oliver,

On Thu, 19 Aug 2021 23:36:34 +0100,
Oliver Upton <oupton@xxxxxxxxxx> wrote:
> 
> Certain VMMs/operators may wish to give their guests the ability to
> initiate a system suspend that could result in the VM being saved to
> persistent storage to be resumed at a later time. The PSCI v1.0
> specification describes an SMC, SYSTEM_SUSPEND, that allows a kernel to
> request a system suspend. This call is optional for v1.0, and KVM
> elected to not support the call in its v1.0 implementation.
> 
> This series adds support for the SYSTEM_SUSPEND PSCI call to KVM/arm64.
> Since this is a system-scoped event, KVM cannot quiesce the VM on its
> own. We add a new system exit type in this series to clue in userspace
> that a suspend was requested. Per the KVM_EXIT_SYSTEM_EVENT ABI, a VMM
> that doesn't care about this event can simply resume the guest without
> issue (we set up the calling vCPU to come out of reset correctly on next
> KVM_RUN).

More idle thoughts on this:

Although the definition of SYSTEM_SUSPEND is very simple from a PSCI
perspective, I don't think it is that simple at the system level,
because PSCI is only concerned with the CPU.

For example, what is a wake-up event? My first approach would be to
consider interrupts to be such events. However, this approach suffers
from at least two issues:

- How do you define which interrupts are actual wake-up events?
  Nothing in the GIC architecture defines what a wake-up is (let alone
  a wake-up event).

- Assuming you have a way to express the above, how do you handle
  wake-ups from interrupts that have their source in the kernel (such
  as timers, irqfd sources)? How do you cope with directly injected
  interrupts?

It looks to me that your implementation can only work with userspace
provided events, which is pretty limited.

Other items worth considering: ongoing DMA, state of the caches at
suspend time, device state in general All of this really needs to be
defined before we can move forward with this feature.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux