Re: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dump core is failed for PAL_HALT)
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. 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. Probably modifying machine_reboot() and machine_power_off() needs modification(paravirtualization) to call shutdown hypercall. I think all the paravirtualization can be done through EFI+PAL calls. Tristan. ___ 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] dump core is failed for PAL_HALT)
Hi, Isaku and Tristan
Thank you for your comments.
Probably modifying machine_reboot() and machine_power_off()
needs modification(paravirtualization) to call shutdown hypercall.
I think all the paravirtualization can be done through EFI+PAL calls.
I fix by using notifier_call and I can shutdown domU.
But I don't try domVTi.
Must we be care about shutdown process of OSes on domVTi?
What do you think?
diff -r dc4a69e66104 linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Fri Jan 19 13:27:52
2007
+0900
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Wed Jan 24 19:27:09
2007
+0900
@@ -64,6 +64,7 @@
#ifdef CONFIG_XEN
#include asm/hypervisor.h
#include asm/xen/xencomm.h
+#include asm/kdebug.h
#endif
#include linux/dma-mapping.h
@@ -95,6 +96,19 @@ xen_panic_event(struct notifier_block *t
static struct notifier_block xen_panic_block = {
xen_panic_event, NULL, 0 /* try to go last */
+};
+
+static int
+xen_poweroff_event(struct notifier_block *this, unsigned long event, void *ptr)
+{
+ if ( event == DIE_MACHINE_HALT )
+ HYPERVISOR_shutdown(SHUTDOWN_poweroff);
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block xen_poweroff_block = {
+ xen_poweroff_event, NULL, 0 /* try to go last */
};
#endif
@@ -448,6 +462,7 @@ setup_arch (char **cmdline_p)
setup_xen_features();
/* Register a call for panic conditions. */
notifier_chain_register(panic_notifier_list, xen_panic_block);
+ notifier_chain_register(ia64die_chain, xen_poweroff_block);
}
#endif
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] dump core is failed for PAL_HALT)
Hi, Probably modifying machine_reboot() and machine_power_off() needs modification(paravirtualization) to call shutdown hypercall. I think all the paravirtualization can be done through EFI+PAL calls. Do Linux/Windows-ia64 use ACPI to shutdown system? If so, we must not be care about VTi domain. 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] dump core is failed for PAL_HALT)
On Wed, Jan 24, 2007 at 07:29:14PM +0900, Akio Takebe wrote: Hi, Probably modifying machine_reboot() and machine_power_off() needs modification(paravirtualization) to call shutdown hypercall. I think all the paravirtualization can be done through EFI+PAL calls. Do Linux/Windows-ia64 use ACPI to shutdown system? Yes. If so, we must not be care about VTi domain. Yes. The issue araises in PV because ACPI is not used to shutdown the system. Tristan. ___ 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] dump core is failed for PAL_HALT)
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
Re: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dump core is failed for PAL_HALT)
Hi, Tristan On Wed, Jan 24, 2007 at 07:29:14PM +0900, Akio Takebe wrote: Hi, Probably modifying machine_reboot() and machine_power_off() needs modification(paravirtualization) to call shutdown hypercall. I think all the paravirtualization can be done through EFI+PAL calls. Do Linux/Windows-ia64 use ACPI to shutdown system? Yes. If so, we must not be care about VTi domain. Yes. The issue araises in PV because ACPI is not used to shutdown the system. Thank you for your answer. I remake my patches, and I'll post soon. 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] dump core is failed for PAL_HALT)
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
[Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dump core is failed for PAL_HALT)
Hi, Isaku and all Thank you for your suggestion. Choice C. Modify PAL_HALT emulation as follows. If other vcpu is left and alive, vcpu is put in sleep. If current is the last vcpu, call domain_shutdown(SHUTDOWN_poweroff). It will be guaranteed that the vcpu which call panic() calls HYPERVISOR_shutdown(SHUTDOWN_crash) via xen_panic_block so that the guest domain's core dump should be created. (I haven't tested it though.) -- I make the patch of choice C. This patch modify PAL_HALT of guest domain. I can dump correctly with my patch. But if I use this patch, I cannot shutdown domU, because linux machine_halt() call cpu_halt from only one cpu. Do anyone know why linux call it from only one cpu? Or do I have miss-reading about that? Best Regards, Akio Takebe domainU_pal_halt.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] dump core is failed for PAL_HALT)
On Wed, Jan 24, 2007 at 11:43:37AM +0900, Akio Takebe wrote: Content-Description: Mail message body Thank you for your suggestion. Choice C. Modify PAL_HALT emulation as follows. If other vcpu is left and alive, vcpu is put in sleep. If current is the last vcpu, call domain_shutdown(SHUTDOWN_poweroff). It will be guaranteed that the vcpu which call panic() calls HYPERVISOR_shutdown(SHUTDOWN_crash) via xen_panic_block so that the guest domain's core dump should be created. (I haven't tested it though.) -- I make the patch of choice C. This patch modify PAL_HALT of guest domain. I can dump correctly with my patch. But if I use this patch, I cannot shutdown domU, because linux machine_halt() call cpu_halt from only one cpu. Do anyone know why linux call it from only one cpu? Or do I have miss-reading about that? According to SDM vol2 11.9, PAL_HALT places cpu in low power state. So the current behaviour that xen/ia64 shutdown unconditionally is wrong. CPU hot-unplug routine also calls cpu_halt(). In that case, only the targeted cpu should be halted. We don't want domain shutdown. Probably modifying machine_reboot() and machine_power_off() needs modification(paravirtualization) to call shutdown hypercall. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
