On Wed, Jun 22, 2022, Limonciello, Mario wrote: > On 6/22/2022 04:53, Grzegorz Jaszczyk wrote: > > It will be problematic since the abort/restore notification could > > arrive too late and therefore the whole system will go to suspend > > thinking that the guest is in desired s2ilde state. Also in this case > > it would be impossible to prevent races and actually making sure that > > the guest is suspended or not. We already had similar discussion with > > Sean earlier in this thread why the notification have to be send just > > before swait_event_exclusive(s2idle_wait_head, s2idle_state == > > S2IDLE_STATE_WAKE) and that the VMM have to have control over guest > > resumption. > > > > Nevertheless if extending acpi_s2idle_dev_ops is possible, why not > > extend it about the hypervisor_notify() and use it in the same place > > where the hypercall is used in this patch? Do you see any issue with > > that? > > If this needs to be a hypercall and the hypercall needs to go at that > specific time, I wouldn't bother with extending acpi_s2idle_dev_ops. The > whole idea there was that this would be less custom and could follow a spec. It doesn't need to be a hypercall though. PIO and MMIO provide the same "exit to host userspace" behavior, and there is zero reason to get KVM involved since KVM (on x86) doesn't deal with platform scoped power management. I get that squeezing this into the ACPI device model is awkward, but forcing KVM into the picture isn't any better. > TBH - given the strong dependency on being the very last command and this > being all Linux specific (you won't need to do something similar with > Windows) - I think the way you already did it makes the most sense. > It seems to me the ACPI device model doesn't really work well for this > scenario.
