RE: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)
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 patch. As you said, Linux on domVTi call acpi_power_off(), then Qemu-dm emulate ACPI S5 state. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)
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 not called from machine_halt(). So if we use halt command to shutdown domain, we cannot halt system... But is this ia64 achtecture specific? I think notifier_chain of ia64die_chain is the best choice. Which is good patch? Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe pm_power_off_version.patch Description: Binary data notifier_call_version.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)
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 list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)
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 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. 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 a domain shutdown for VTI domains? Hmm. Some OSes on VTI may use cpu_halt() on all vcpu. So I add printk like call PAL_HALT on all cpu, and call domain_shutdown() for VTI domain. Is this OK? Best Regards, Akio Takebe On Wed, 2007-01-24 at 11:14 +0100, [EMAIL PROTECTED] wrote: Selon Isaku Yamahata [EMAIL PROTECTED]: On Wed, Jan 24, 2007 at 11:43:37AM +0900, Akio Takebe wrote: [...] According to SDM vol2 11.9, PAL_HALT places cpu in low power state. Correct. So the current behaviour that xen/ia64 shutdown unconditionally is wrong. Yes, but that's the code in linux/ia64. Why linux/ia64 doesn't call the shutdown EFI runtime service ? I don't know. Maybe Alex knows the answer. I think we need to be sure we're getting the correct expected user behavior for domains. A user expects the following on real hardware: * halt: Machine is stopped, not shutdown, not rebooted. Linux/ia64 uses PAL_HALT for this. * restart/reboot: Machine is reset. Linux/ia64 uses efi.reset_system for this. * poweroff: Machine is turned off. Linux/ia64 uses ACPI S5 power state if pm_power_off is set, otherwise behaves as if halted. 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. 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. 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 a domain shutdown for VTI domains? CPU hot-unplug routine also calls cpu_halt(). In that case, only the targeted cpu should be halted. We don't want domain shutdown. If the last vcpu calls PAL_HALT, the domain can be safely shut down. It's safe, but I don't agree that it should. Thanks, Alex ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)
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. Maybe all vcpus in cpu_halt() should only be cause for a domain shutdown for VTI domains? Hmm. Some OSes on VTI may use cpu_halt() on all vcpu. So I add printk like call PAL_HALT on all cpu, and call domain_shutdown() for VTI domain. Is this OK? Hi Akio, I would prioritize a poweroff shutting down a domain over halt making a domain stall. So for VTI domains, this sounds ok. I'd skip the printk though, it seems overly verbose. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)
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 a domain shutdown for VTI domains? I think VTI support S5, if not it should :-) In VTI side, ACPI is emulated by ACPI module of Qemu. I think it supports S5. Anthony. Tristan Gingold write on 2007年1月25日 11:09: On Wed, Jan 24, 2007 at 09:19:09AM -0700, Alex Williamson wrote: On Wed, 2007-01-24 at 11:14 +0100, [EMAIL PROTECTED] wrote: Selon Isaku Yamahata [EMAIL PROTECTED]: On Wed, Jan 24, 2007 at 11:43:37AM +0900, Akio Takebe wrote: [...] According to SDM vol2 11.9, PAL_HALT places cpu in low power state. Correct. So the current behaviour that xen/ia64 shutdown unconditionally is wrong. Yes, but that's the code in linux/ia64. Why linux/ia64 doesn't call the shutdown EFI runtime service ? I don't know. Maybe Alex knows the answer. I think we need to be sure we're getting the correct expected user behavior for domains. A user expects the following on real hardware: * halt: Machine is stopped, not shutdown, not rebooted. Linux/ia64 uses PAL_HALT for this. * restart/reboot: Machine is reset. Linux/ia64 uses efi.reset_system for this. * poweroff: Machine is turned off. Linux/ia64 uses ACPI S5 power state if pm_power_off is set, otherwise behaves as if halted. 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. Thanks for the details. So current Xen/ia64 PAL_HALT behavior is not correct. 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. 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 a domain shutdown for VTI domains? I think VTI support S5, if not it should :-) [...] Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
