Hi, Anthony
Hi, Anthony
In VTI side, ACPI is emulated by ACPI module of Qemu.
I think it supports S5.
Good news. But I look like Qemu don't trap acpi_power_off called by linux on
VTI.
I'll investigate it.
I'm sorry, the GFW was very old.
If I update the latest GFW, I can shutdown domVTi with my
Hi, Alex and all
Machine restart/reboot should (and does) happen transparently when Xen
catches the EFI call. To support poweroff, I think we should set
pm_power_off to a Xen specific hypervisor shutdown routine. The
abstraction is already in place to do this.
OK, I'll try it.
pm_power_off is
Hi, Anthony
In VTI side, ACPI is emulated by ACPI module of Qemu.
I think it supports S5.
Good news. But I look like Qemu don't trap acpi_power_off called by linux on
VTI.
I'll investigate it.
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing
Hi, Alex
Thank you for your elaboration.
I agree your opinion.
So, for PV domains, cpu_halt() should just take the vcpu offline. I
don't think there's any reason to special case the last vcpu going
offline and shutdown the domain. That's not what real hardware does.
Exactly.
Machine
On Thu, 2007-01-25 at 10:02 +0900, Akio Takebe wrote:
Do VTI domains implement enough ACPI to provide the OS a fake S5 power
state? If not, a PV-on-HVM driver could set pm_power_off and use a
hypercall, but that means HVM domains would need a Xen driver for some
pretty basic functionality.
Do VTI domains implement enough ACPI to provide the OS a fake S5
power state? If not, a PV-on-HVM driver could set pm_power_off and
use a hypercall, but that means HVM domains would need a Xen driver
for some pretty basic functionality. Maybe all vcpus in cpu_halt()
should only be cause for
