On 3 March 2015 at 20:06, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > On 03/03/2015 11:56, Alex Bennée wrote: >> > > This adds the saving and restore of the current Multi-Processing state >> > > of the machine. While the KVM_GET/SET_MP_STATE API exposes a number of >> > > potential states for x86 we only use two for ARM. Either the process is >> > > running or not. >> > >> > By this you mean "is the CPU in the PSCI powered down state or not", >> > right? >> >> From the vcpu's perspective it is either running or not. However it is >> the same mechanism that is used when PSCI_0_2_FN_CPU_OFF is passed the >> VM, internally setting vcpu->arch.paused. Well, it has to be (ABI defined to be) identical with being PSCI powered down/up, because that's how userspace is going to be treating it. If we might tell userspace we're in the "not running" state for other cases than PSCI-powered-down then we probably need to consider separating those out into separate states. > I suggest that you define a new MP_STATE constant for this. HALTED in > x86 and s390 is the state an ARM processor enters when you execute wfi. Architecturally the CPU doesn't have to enter any state at all if you execute a WFI -- it might be implemented as "go to low power state and wait for an interrupt" or "go low power but maybe be unnecessarily woken up" or "nop, do nothing"... > Right now this is not migrated on ARM if I remember correctly, but > perhaps you'll want to add it in the future. ...which is why we don't need to migrate this: it just means that migration during WFI causes an unnecessary-wakeup, which is architecturally fine. -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
