[PATCH 0/5][IA64][HVM] Windows crashdump support

[PATCH 0/5][IA64][HVM] Windows crashdump support

[Masaki Kanno]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 783 bytes --]

Hi all,

I resend these patches. Could you comment them?

They are able to collect a crashdump of the Windows on HVM 
domain on ia64. 

In the ia64 machine, there is an INIT switch. By pushing the 
INIT switch, an INIT interruption is generated. The INIT 
interruption triggers off when the Windows collects the 
crashdump. (I attach a screenshot of the Windows crashdump.)

Currently, we don't provide a virtual INIT switch. Therefore, 
Windows on HVM domain is not able to collect the crashdump. 
We provide a new xm command as the virtual INIT switch. 

The new xm command: xm os-init <Domain>

Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>
Signed-off-by: Zhang Xin <xing.z.zhang@intel.com>

Best regards,
 Kan


[-- Attachment #2: crashdump.png --]
[-- Type: image/png, Size: 240767 bytes --]

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

[PATCH 1/5][IA64][HVM] Windows crashdump support: Xen common side

[Masaki Kanno]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 25 bytes --]

[1/5] Xen common side. 


[-- Attachment #2: xm_osinit.xen_common.patch --]
[-- Type: application/octet-stream, Size: 2143 bytes --]

diff -r 200a9c6deeb3 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Mon Jan 22 16:27:03 2007 +0000
+++ b/xen/include/public/domctl.h	Tue Jan 23 00:53:26 2007 +0900
@@ -358,12 +358,14 @@ typedef struct xen_domctl_ioport_permiss
 typedef struct xen_domctl_ioport_permission xen_domctl_ioport_permission_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_ioport_permission_t);
 
+
 #define XEN_DOMCTL_hypercall_init    22
 struct xen_domctl_hypercall_init {
     uint64_t  gmfn;            /* GMFN to be initialised */
 };
 typedef struct xen_domctl_hypercall_init xen_domctl_hypercall_init_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_hypercall_init_t);
+
 
 #define XEN_DOMCTL_arch_setup        23
 #define _XEN_DOMAINSETUP_hvm_guest 0
@@ -381,12 +383,14 @@ typedef struct xen_domctl_arch_setup {
 } xen_domctl_arch_setup_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_arch_setup_t);
 
+
 #define XEN_DOMCTL_settimeoffset     24
 struct xen_domctl_settimeoffset {
     int32_t  time_offset_seconds; /* applied to domain wallclock time */
 };
 typedef struct xen_domctl_settimeoffset xen_domctl_settimeoffset_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_settimeoffset_t);
+
  
 #define HVM_CTXT_SIZE        6144
 typedef struct hvm_domain_context {
@@ -396,19 +400,24 @@ typedef struct hvm_domain_context {
 } hvm_domain_context_t;
 DEFINE_XEN_GUEST_HANDLE(hvm_domain_context_t);
 
-#define XEN_DOMCTL_gethvmcontext   33
-#define XEN_DOMCTL_sethvmcontext   34
+#define XEN_DOMCTL_gethvmcontext     33
+#define XEN_DOMCTL_sethvmcontext     34
 typedef struct xen_domctl_hvmcontext {
     XEN_GUEST_HANDLE(hvm_domain_context_t) ctxt;  /* IN/OUT */
 } xen_domctl_hvmcontext_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_hvmcontext_t);
 
-#define XEN_DOMCTL_real_mode_area     26
+
+#define XEN_DOMCTL_real_mode_area    26
 struct xen_domctl_real_mode_area {
     uint32_t log; /* log2 of Real Mode Area size */
 };
 typedef struct xen_domctl_real_mode_area xen_domctl_real_mode_area_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_real_mode_area_t);
+
+
+#define XEN_DOMCTL_send_init         27
+
 
 #define XEN_DOMCTL_set_compat        42
 #define XEN_DOMCTL_set_native        43

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

[PATCH 2/5][IA64][HVM] Windows crashdump support: Xen arch_ia64 side

[Masaki Kanno]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 28 bytes --]

[2/5] Xen arch_ia64 side. 


[-- Attachment #2: xm_osinit.xen_arch_ia64.patch --]
[-- Type: application/octet-stream, Size: 3429 bytes --]

diff -r 200a9c6deeb3 xen/arch/ia64/vmx/vlsapic.c
--- a/xen/arch/ia64/vmx/vlsapic.c	Mon Jan 22 16:27:03 2007 +0000
+++ b/xen/arch/ia64/vmx/vlsapic.c	Fri Jan 19 13:07:07 2007 +0900
@@ -493,6 +493,18 @@ chk_irq_exit:
 }
 
 /*
+ * Set a INIT interruption request to vcpu[0] of target domain.
+ * The INIT interruption is injected into each vcpu by guest firmware.
+ */
+void vmx_pend_pal_init(struct domain *d)
+{
+    VCPU *vcpu;
+
+    vcpu = d->vcpu[0];
+    vcpu->arch.arch_vmx.pal_init_pending = 1;
+}
+
+/*
  * Only coming from virtualization fault.
  */
 void guest_write_eoi(VCPU *vcpu)
@@ -636,6 +648,14 @@ static void vlsapic_deliver_ipi(VCPU *vc
         panic_domain(NULL, "Deliver reserved IPI!\n");
         break;
     }
+}
+
+/*
+ * Deliver the INIT interruption to guest.
+ */
+void deliver_pal_init(VCPU *vcpu)
+{
+    vlsapic_deliver_ipi(vcpu, SAPIC_INIT, 0);
 }
 
 /*
diff -r 200a9c6deeb3 xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c	Mon Jan 22 16:27:03 2007 +0000
+++ b/xen/arch/ia64/vmx/vmx_process.c	Fri Jan 19 15:44:49 2007 +0900
@@ -209,6 +209,12 @@ void leave_hypervisor_tail(struct pt_reg
         if (v->vcpu_id == 0) {
             int callback_irq =
                 d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ];
+            if ( v->arch.arch_vmx.pal_init_pending ) {
+                /*inject INIT interruption to guest pal*/
+                v->arch.arch_vmx.pal_init_pending = 0;
+                deliver_pal_init(v);
+                return;
+            }
             if (callback_irq != 0 && local_events_need_delivery()) {
                 /* change level for para-device callback irq */
                 /* use level irq to send discrete event */
diff -r 200a9c6deeb3 xen/arch/ia64/xen/dom0_ops.c
--- a/xen/arch/ia64/xen/dom0_ops.c	Mon Jan 22 16:27:03 2007 +0000
+++ b/xen/arch/ia64/xen/dom0_ops.c	Fri Jan 19 15:44:49 2007 +0900
@@ -174,6 +174,20 @@ long arch_do_domctl(xen_domctl_t *op, XE
         put_domain(d);
     }
     break;
+
+    case XEN_DOMCTL_send_init:
+    {
+        struct domain *d = find_domain_by_id(op->domain);
+
+        if ( d == NULL ) {
+            ret = -ESRCH;
+            break;
+        }
+        vmx_pend_pal_init(d);
+        put_domain(d);
+    }
+    break;
+
     default:
         printk("arch_do_domctl: unrecognized domctl: %d!!!\n",op->cmd);
         ret = -ENOSYS;
diff -r 200a9c6deeb3 xen/include/asm-ia64/vmx.h
--- a/xen/include/asm-ia64/vmx.h	Mon Jan 22 16:27:03 2007 +0000
+++ b/xen/include/asm-ia64/vmx.h	Fri Jan 19 13:07:07 2007 +0900
@@ -55,6 +55,8 @@ extern void vmx_relinquish_vcpu_resource
 extern void vmx_relinquish_vcpu_resources(struct vcpu *v);
 extern void vmx_die_if_kernel(char *str, struct pt_regs *regs, long err);
 extern void vmx_send_assist_req(struct vcpu *v);
+extern void deliver_pal_init(struct vcpu *vcpu);
+extern void vmx_pend_pal_init(struct domain *d);
 
 static inline vcpu_iodata_t *get_vio(struct domain *d, unsigned long cpu)
 {
diff -r 200a9c6deeb3 xen/include/asm-ia64/vmx_vpd.h
--- a/xen/include/asm-ia64/vmx_vpd.h	Mon Jan 22 16:27:03 2007 +0000
+++ b/xen/include/asm-ia64/vmx_vpd.h	Fri Jan 19 13:07:07 2007 +0900
@@ -99,6 +99,7 @@ struct arch_vmx_struct {
     unsigned long   flags;
     unsigned long   xen_port;
     unsigned char   xtp;
+    unsigned char   pal_init_pending;
 #ifdef VTI_DEBUG
     unsigned long  ivt_current;
     struct ivt_debug ivt_debug[IVT_DEBUG_MAX];

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

[PATCH 3/5][IA64][HVM] Windows crashdump support: Linux arch_ia64 side

[Masaki Kanno]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 30 bytes --]

[3/5] Linux arch_ia64 side. 


[-- Attachment #2: xm_osinit.linux_arch_ia64.patch --]
[-- Type: application/octet-stream, Size: 518 bytes --]

diff -r 200a9c6deeb3 linux-2.6-xen-sparse/arch/ia64/xen/xcom_privcmd.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/xcom_privcmd.c	Mon Jan 22 16:27:03 2007 +0000
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/xcom_privcmd.c	Fri Jan 19 13:07:06 2007 +0900
@@ -303,6 +303,7 @@ xencomm_privcmd_domctl(privcmd_hypercall
 	case XEN_DOMCTL_hypercall_init:
 	case XEN_DOMCTL_arch_setup:
 	case XEN_DOMCTL_settimeoffset:
+	case XEN_DOMCTL_send_init:
 		break;
 	default:
 		printk("%s: unknown domctl cmd %d\n", __func__, kern_op.cmd);

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

[PATCH 4/5][IA64][HVM] Windows crashdump support: Tools common side

[Masaki Kanno]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 27 bytes --]

[4/5] Tools common side. 


[-- Attachment #2: xm_osinit.tools_common.patch --]
[-- Type: application/octet-stream, Size: 4669 bytes --]

diff -r 200a9c6deeb3 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Mon Jan 22 16:27:03 2007 +0000
+++ b/tools/libxc/xenctrl.h	Tue Jan 23 01:11:31 2007 +0900
@@ -410,6 +410,16 @@ int xc_sched_credit_domain_get(int xc_ha
                                uint32_t domid,
                                struct xen_domctl_sched_credit *sdom);
 
+/**
+ * This function sends INIT interruption to a HVM domain of ia64.
+ *
+ * @parm xc_handle a handle to an open hypervisor interface
+ * @parm domid the domain id to send 
+ * return 0 on success, -1 on failure
+ */
+int xc_hvm_domain_send_init(int xc_handle,
+                            uint32_t domid);
+
 /*
  * EVENT CHANNEL FUNCTIONS
  */
diff -r 200a9c6deeb3 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Mon Jan 22 16:27:03 2007 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Tue Jan 23 08:35:25 2007 +0900
@@ -1014,6 +1014,14 @@ static PyObject *pyxc_prose_build(XcObje
 }
 #endif /* powerpc */
 
+#ifdef __ia64__
+static PyObject *pyxc_hvm_domain_send_init(XcObject *self,
+                                       PyObject *args)
+{
+    return dom_op(self, args, xc_hvm_domain_send_init);
+}
+#endif /* __ia64__ */
+
 static PyMethodDef pyxc_methods[] = {
     { "handle",
       (PyCFunction)pyxc_handle,
@@ -1360,6 +1368,15 @@ static PyMethodDef pyxc_methods[] = {
       " vcpus   [int, 1]:   Number of Virtual CPUS in domain.\n\n"
       "Returns: [int] 0 on success; -1 on error.\n" },
 #endif /* __powerpc */
+
+#ifdef __ia64__
+    { "arch_hvm_domain_send_init", 
+      (PyCFunction)pyxc_hvm_domain_send_init, 
+      METH_VARARGS, "\n"
+      "Send INIT interruption to a domain.\n"
+      " dom [int]: Identifier of domain to be sent INIT interruption.\n\n"
+      "Returns: [int] 0 on success; -1 on error.\n" },
+#endif /* __ia64__ */
 
     { NULL, NULL, 0, NULL }
 };
diff -r 200a9c6deeb3 tools/python/xen/xend/XendDomain.py
--- a/tools/python/xen/xend/XendDomain.py	Mon Jan 22 16:27:03 2007 +0000
+++ b/tools/python/xen/xend/XendDomain.py	Tue Jan 23 08:35:25 2007 +0900
@@ -46,6 +46,7 @@ from xen.xend.XendDevices import XendDev
 from xen.xend.XendDevices import XendDevices
 
 from xen.xend.xenstore.xstransact import xstransact
+from xen.xend.xenstore.xsutil import GetDomainPath
 from xen.xend.xenstore.xswatch import xswatch
 from xen.util import mkdir, security
 from xen.xend import uuid
@@ -1415,6 +1416,33 @@ class XendDomain:
         except Exception, ex:
             raise XendError(str(ex))
 
+    def domain_send_init(self, domid):
+        """Send INIT interruption to a domain for ia64.
+
+        @param domid: Domain ID or Name
+        @type domid: int or string.
+        @raise XendError: failed to send INIT interruption
+        @raise XendInvalidDomain: Domain is not valid        
+        @rtype: 0
+        """
+        mch = os.uname()[4]
+        if mch != 'ia64':
+            raise XendError("This command is Xen/ia64 only")
+
+        dominfo = self.domain_lookup_nr(domid)
+        if not dominfo:
+            raise XendInvalidDomain(str(domid))
+
+        vmpath = xstransact.Read(GetDomainPath(dominfo.getDomid()), "vm")
+        ostype = xstransact.Read(vmpath, "image/ostype")
+        if ostype != 'hvm':
+            raise XendError("This command is HVM domain only")
+
+        try:
+            return xc.arch_hvm_domain_send_init(dominfo.getDomid())
+        except Exception, ex:
+            raise XendError(str(ex))
+    
 
 def instance():
     """Singleton constructor. Use this instead of the class constructor.
diff -r 200a9c6deeb3 tools/python/xen/xm/main.py
--- a/tools/python/xen/xm/main.py	Mon Jan 22 16:27:03 2007 +0000
+++ b/tools/python/xen/xm/main.py	Fri Jan 19 13:07:07 2007 +0900
@@ -140,6 +140,7 @@ SUBCOMMAND_HELP = {
     'vcpu-set'    : ('<Domain> <vCPUs>',
                      'Set the number of active VCPUs for allowed for the'
                      ' domain.'),
+    'os-init'     : ('<Domain>', 'Send a INIT to a domain.'),
 
     # device commands
 
@@ -274,6 +275,7 @@ domain_commands = [
     "mem-max",
     "mem-set",
     "migrate",
+    "os-init",
     "pause",
     "reboot",
     "rename",
@@ -1328,6 +1330,11 @@ def xm_sysrq(args):
     req = args[1]
     server.xend.domain.send_sysrq(dom, req)    
 
+def xm_osinit(args):
+    arg_check(args, "os-init", 1)
+    dom = args[0]
+    server.xend.domain.send_init(dom)
+
 def xm_top(args):
     arg_check(args, "top", 0)
 
@@ -1652,6 +1659,7 @@ commands = {
     "uptime": xm_uptime,
     "suspend": xm_suspend,
     "list": xm_list,
+    "os-init": xm_osinit,
     # memory commands
     "mem-max": xm_mem_max,
     "mem-set": xm_mem_set,

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

[PATCH 5/5][IA64][HVM] Windows crashdump support: Tools arch_ia64 side

[Masaki Kanno]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 30 bytes --]

[5/5] Tools arch_ia64 side. 


[-- Attachment #2: xm_osinit.tools_arch_ia64.patch --]
[-- Type: application/octet-stream, Size: 1038 bytes --]

diff -r 200a9c6deeb3 tools/libxc/ia64/Makefile
--- a/tools/libxc/ia64/Makefile	Mon Jan 22 16:27:03 2007 +0000
+++ b/tools/libxc/ia64/Makefile	Tue Jan 23 01:20:47 2007 +0900
@@ -1,5 +1,6 @@ CTRL_SRCS-y += ia64/xc_ia64_stubs.c
 CTRL_SRCS-y += ia64/xc_ia64_stubs.c
 
 GUEST_SRCS-y += ia64/xc_ia64_hvm_build.c
+GUEST_SRCS-y += ia64/xc_ia64_hvm_domain.c
 GUEST_SRCS-y += ia64/xc_ia64_linux_save.c
 GUEST_SRCS-y += ia64/xc_ia64_linux_restore.c
diff -r 200a9c6deeb3 tools/libxc/ia64/xc_ia64_hvm_domain.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/ia64/xc_ia64_hvm_domain.c	Tue Jan 23 01:26:18 2007 +0900
@@ -0,0 +1,21 @@
+#include "xc_private.h"
+#include "xen/arch-ia64.h"
+
+int
+xc_hvm_domain_send_init(int xc_handle, uint32_t domid)
+{
+    DECLARE_DOMCTL;
+    domctl.cmd = XEN_DOMCTL_send_init;
+    domctl.domain = (domid_t)domid;
+    return do_domctl(xc_handle, &domctl);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support

[Keir Fraser]

On 23/1/07 2:40 am, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:

> I resend these patches. Could you comment them?
> 
> They are able to collect a crashdump of the Windows on HVM
> domain on ia64. 

It just seems a lot of plumbing for something not very useful, at least to
users. You can dump memory via 'xm dump' after all if that's your goal (or
will be able to when Isaku's patches go in). Would anyone else in the ai64
community like to speak up for these patches?

 -- Keir

Re: Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support

[Jürgen Groß]

Keir Fraser wrote:
> On 23/1/07 2:40 am, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:
> 
>> I resend these patches. Could you comment them?
>>
>> They are able to collect a crashdump of the Windows on HVM
>> domain on ia64. 
> 
> It just seems a lot of plumbing for something not very useful, at least to
> users. You can dump memory via 'xm dump' after all if that's your goal (or
> will be able to when Isaku's patches go in). Would anyone else in the ai64
> community like to speak up for these patches?

I think there is a big difference between 'xm dump' and a dump done by domU.
Detailed error analysis might be possible only with a dump taken via domU as
the dump analysis tools will work in most cases on the domU specific dump
format only.
Outside the Linux world :-) (e.g. in most UNIX flavors) crash dump analysis
is very useful!
I would strongly support Masaki's patches.

Juergen

-- 
Juergen Gross                Telephone: +49 (0) 89 636 47950
Fujitsu Siemens Computers    Telefax:   +49 (0) 89 636 40638
Otto-Hahn-Ring 6             e-mail:    juergen.gross@fujitsu-siemens.com
81739 Muenchen, Germany      Internet:  http://www.fujitsu-siemens.com

Re: Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support

[Keir Fraser]

On 23/1/07 7:47 am, "Jürgen Groß" <juergen.gross@fujitsu-siemens.com> wrote:

>> It just seems a lot of plumbing for something not very useful, at least to
>> users. You can dump memory via 'xm dump' after all if that's your goal (or
>> will be able to when Isaku's patches go in). Would anyone else in the ai64
>> community like to speak up for these patches?
> 
> I think there is a big difference between 'xm dump' and a dump done by domU.
> Detailed error analysis might be possible only with a dump taken via domU as
> the dump analysis tools will work in most cases on the domU specific dump
> format only.
> Outside the Linux world :-) (e.g. in most UNIX flavors) crash dump analysis
> is very useful!
> I would strongly support Masaki's patches.

If that's the aim then perhaps the xm command should be given a better name.
'xm os-init' is rather meaningless outside the context of physical INIT
buttons on ia64 systems -- not a very generic concept to export to a VM
management tool! Perhaps 'xm os-dump' with a guest-specific backend
implementation in xend (default to fail with an error message).

 -- Keir

Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support

[Keir Fraser]

On 23/1/07 2:40 am, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:

> In the ia64 machine, there is an INIT switch. By pushing the
> INIT switch, an INIT interruption is generated. The INIT
> interruption triggers off when the Windows collects the
> crashdump. (I attach a screenshot of the Windows crashdump.)

Does ia64 Windows generate a dump if you send it an NMI? That would be a
more generic mechanism that would allow x86 HVM to share the same domctl or
hvm_op. Otherwise we need a send_init hypercall for ia64 and a send_nmi
hypercall for x86, or we need a more vague generic name like
"trigger_dump_switch" (which actually is rather attractive now I think about
it).

 -- Keir

Re: Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support

[Tristan Gingold]

On Tue, Jan 23, 2007 at 08:06:23AM +0000, Keir Fraser wrote:
> On 23/1/07 2:40 am, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:
> 
> > In the ia64 machine, there is an INIT switch. By pushing the
> > INIT switch, an INIT interruption is generated. The INIT
> > interruption triggers off when the Windows collects the
> > crashdump. (I attach a screenshot of the Windows crashdump.)
> 
> Does ia64 Windows generate a dump if you send it an NMI? That would be a
> more generic mechanism that would allow x86 HVM to share the same domctl or
> hvm_op. Otherwise we need a send_init hypercall for ia64 and a send_nmi
> hypercall for x86, or we need a more vague generic name like
> "trigger_dump_switch" (which actually is rather attractive now I think about
> it).
I support the feature too.

I think being able to post an NMI/INIT is a good feature.  It allows you
to test the feature if your bare hardware don't have it.

Maybe os-init is not the best name.
Maybe the balance between code in hypervisor (very small) and code in xm
(larger) is not very good, but difficule to improve !


Tristan.

Re: [PATCH 0/5][IA64][HVM] Windows crashdump support

[Masaki Kanno]

>On 23/1/07 2:40 am, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:
>
>> In the ia64 machine, there is an INIT switch. By pushing the
>> INIT switch, an INIT interruption is generated. The INIT
>> interruption triggers off when the Windows collects the
>> crashdump. (I attach a screenshot of the Windows crashdump.)
>
>Does ia64 Windows generate a dump if you send it an NMI? That would be a
>more generic mechanism that would allow x86 HVM to share the same domctl or
>hvm_op. Otherwise we need a send_init hypercall for ia64 and a send_nmi
>hypercall for x86, or we need a more vague generic name like
>"trigger_dump_switch" (which actually is rather attractive now I think about
>it).

Hi Keir,

No, the ia64 Windows does not generate the crashdump by the NMI. 
In the ia64 machine, the NMI interruption and the INIT interruption 
are generated by different mechanism. 
I don't adhere to the name of 'send_init'. Rather I think that 
'trigger_dump_switch' which you named it is better. 

Best regards,
 Kan

Re: [Xen-ia64-devel] Re: [PATCH 0/5][IA64][HVM] Windows crashdump support

[John Levon]

On Tue, Jan 23, 2007 at 08:00:40AM +0000, Keir Fraser wrote:

> >> It just seems a lot of plumbing for something not very useful, at least to
> >> users. You can dump memory via 'xm dump' after all if that's your goal (or
> >> will be able to when Isaku's patches go in). Would anyone else in the ai64
> >> community like to speak up for these patches?
> > 
> > I think there is a big difference between 'xm dump' and a dump done by domU.
> > Detailed error analysis might be possible only with a dump taken via domU as
> > the dump analysis tools will work in most cases on the domU specific dump
> > format only.
> > Outside the Linux world :-) (e.g. in most UNIX flavors) crash dump analysis
> > is very useful!
> > I would strongly support Masaki's patches.
> 
> If that's the aim then perhaps the xm command should be given a better name.
> 'xm os-init' is rather meaningless outside the context of physical INIT
> buttons on ia64 systems -- not a very generic concept to export to a VM
> management tool! Perhaps 'xm os-dump' with a guest-specific backend
> implementation in xend (default to fail with an error message).

I'd like to see a generic command that encompasses both os-init and
sysrq. We support sysrq 'b' but feel a bit silly having that command
name. Ideally we'd hide (but still support) 'xm sysrq' too.

regards
john

Re: [Xen-ia64-devel] Re: [PATCH 0/5][IA64][HVM] Windows crashdump support

[Keir Fraser]

On 23/1/07 13:58, "John Levon" <levon@movementarian.org> wrote:

>> If that's the aim then perhaps the xm command should be given a better name.
>> 'xm os-init' is rather meaningless outside the context of physical INIT
>> buttons on ia64 systems -- not a very generic concept to export to a VM
>> management tool! Perhaps 'xm os-dump' with a guest-specific backend
>> implementation in xend (default to fail with an error message).
> 
> I'd like to see a generic command that encompasses both os-init and
> sysrq. We support sysrq 'b' but feel a bit silly having that command
> name. Ideally we'd hide (but still support) 'xm sysrq' too.

Given that some of this is OS and/or arch specific, it may be hard to
concoct general names. At least the concept of a hardware 'dump switch' is
fairly well known, even if the implementation differs a bit across
architectures. I suppose we could provide better names for some of the more
useful Linux sysrq commands, provide a better / more general interface to
them (both at the xm level and the xenbus level) and encourage other PV
guests to support the new interface.

 -- Keir

Re: Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support

[Masaki Kanno]

>>> It just seems a lot of plumbing for something not very useful, at least to
>>> users. You can dump memory via 'xm dump' after all if that's your goal (or
>>> will be able to when Isaku's patches go in). Would anyone else in the ai64
>>> community like to speak up for these patches?
>> 
>> I think there is a big difference between 'xm dump' and a dump done by 
>> domU.
>> Detailed error analysis might be possible only with a dump taken via domU
>>  as
>> the dump analysis tools will work in most cases on the domU specific dump
>> format only.
>> Outside the Linux world :-) (e.g. in most UNIX flavors) crash dump analysis
>> is very useful!
>> I would strongly support Masaki's patches.
>
>If that's the aim then perhaps the xm command should be given a better name.
>'xm os-init' is rather meaningless outside the context of physical INIT
>buttons on ia64 systems -- not a very generic concept to export to a VM
>management tool! Perhaps 'xm os-dump' with a guest-specific backend
>implementation in xend (default to fail with an error message).

Hi,

Thanks for your idea. 
I thought about some general concept command name, too. I enumerate 
below it and your idea.

 A) xm os-dump
 B) xm dump-trigger
 C) xm dump-core --trigger
 D) xm dump-switch

Any command name?

Best regards,
 Kan

Re: Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windowscrashdump support

[Masaki Kanno]

>On Tue, Jan 23, 2007 at 08:06:23AM +0000, Keir Fraser wrote:
>> On 23/1/07 2:40 am, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:
>> 
>> > In the ia64 machine, there is an INIT switch. By pushing the
>> > INIT switch, an INIT interruption is generated. The INIT
>> > interruption triggers off when the Windows collects the
>> > crashdump. (I attach a screenshot of the Windows crashdump.)
>> 
>> Does ia64 Windows generate a dump if you send it an NMI? That would be a
>> more generic mechanism that would allow x86 HVM to share the same domctl or
>> hvm_op. Otherwise we need a send_init hypercall for ia64 and a send_nmi
>> hypercall for x86, or we need a more vague generic name like
>> "trigger_dump_switch" (which actually is rather attractive now I think 
>> about
>> it).
>I support the feature too.
>
>I think being able to post an NMI/INIT is a good feature.  It allows you
>to test the feature if your bare hardware don't have it.
>

Hi Tristan,

Thanks for your comments. 

>Maybe os-init is not the best name.

Maybe os-init is not the best command name as you say. If you have idea 
of command name, could you send it?

>Maybe the balance between code in hypervisor (very small) and code in xm
>(larger) is not very good, but difficule to improve !

I examined oneself. I should have checked a target domain (HVM domain or 
PV domain) in hypervisor. I will send the patch which moved the check of 
target domain into hypervisor. Maybe not difficult to improve.

Best regards,
 Kan

Re: [Xen-ia64-devel] Re: [PATCH 0/5][IA64][HVM] Windowscrashdump support

[Tristan Gingold]

On Wed, Jan 24, 2007 at 01:19:37AM +0900, Masaki Kanno wrote:
[...]
> Hi Tristan,
> 
> Thanks for your comments. 
> 
> >Maybe os-init is not the best name.
> 
> Maybe os-init is not the best command name as you say. If you have idea 
> of command name, could you send it?
something like
xm trigger init|reset|nmi

> >Maybe the balance between code in hypervisor (very small) and code in xm
> >(larger) is not very good, but difficule to improve !
> 
> I examined oneself. I should have checked a target domain (HVM domain or 
> PV domain) in hypervisor. I will send the patch which moved the check of 
> target domain into hypervisor. Maybe not difficult to improve.
I think it is normal xm code is bigger than hypervisor.  But this makes x86
people not very happy!

BTW, it would be nice if the vcpu number could be specified!

Tristan.

Re: [Xen-ia64-devel] Re: [PATCH 0/5][IA64][HVM] Windowscrashdump support

[Keir Fraser]

On 23/1/07 16:32, "Tristan Gingold" <tgingold@free.fr> wrote:

>> Maybe os-init is not the best command name as you say. If you have idea
>> of command name, could you send it?
> something like
> xm trigger init|reset|nmi

This could be acceptable, mapping to a domctl command with type enumeration
argument. Specifying vcpu would indeed make sense. It's not clear that such
a flexible interface would really be needed (maybe xm os-dump <vcpu> would
suffice, mapping to the usual 'hardware dump switch' method for the
particular architecture?) but it's better than 'xm os-init' which I
definitely dislike, and maybe the extra flexibility could turn out to be
useful.

 -- Keir

Re: [Xen-ia64-devel] Re: [PATCH 0/5][IA64][HVM] Windowscrashdump support

[Tristan Gingold]

On Tue, Jan 23, 2007 at 04:36:57PM +0000, Keir Fraser wrote:
> On 23/1/07 16:32, "Tristan Gingold" <tgingold@free.fr> wrote:
> 
> >> Maybe os-init is not the best command name as you say. If you have idea
> >> of command name, could you send it?
> > something like
> > xm trigger init|reset|nmi
> 
> This could be acceptable, mapping to a domctl command with type enumeration
> argument. Specifying vcpu would indeed make sense. It's not clear that such
> a flexible interface would really be needed (maybe xm os-dump <vcpu> would
> suffice, mapping to the usual 'hardware dump switch' method for the
> particular architecture?) but it's better than 'xm os-init' which I
> definitely dislike, and maybe the extra flexibility could turn out to be
> useful.
For sure this is an export-only command.
I don't really like the xm os-dump name, because the action of init/nmi is
up to the domain.  It may or not dump.

Tristan.

Re: Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windowscrashdump support

[Masaki Kanno]

>On Tue, Jan 23, 2007 at 04:36:57PM +0000, Keir Fraser wrote:
>> On 23/1/07 16:32, "Tristan Gingold" <tgingold@free.fr> wrote:
>> 
>> >> Maybe os-init is not the best command name as you say. If you have idea
>> >> of command name, could you send it?
>> > something like
>> > xm trigger init|reset|nmi
>> 
>> This could be acceptable, mapping to a domctl command with type enumeration
>> argument. Specifying vcpu would indeed make sense. It's not clear that such
>> a flexible interface would really be needed (maybe xm os-dump <vcpu> would
>> suffice, mapping to the usual 'hardware dump switch' method for the
>> particular architecture?) but it's better than 'xm os-init' which I
>> definitely dislike, and maybe the extra flexibility could turn out to be
>> useful.
>For sure this is an export-only command.
>I don't really like the xm os-dump name, because the action of init/nmi is
>up to the domain.  It may or not dump.

Hi Tristan and Keir and all,

Thanks for your idea and comments.
I will remake and resend these patches in the following command syntax. 

 xm trigger <Domain> <VCPU> <init|reset|nmi>

Best regards,
 Kan

Re: [Xen-ia64-devel] Re: [PATCH 0/5][IA64][HVM] Windowscrashdump support

[Tristan Gingold]

On Wed, Jan 24, 2007 at 02:27:42PM +0900, Masaki Kanno wrote:
[...]
> Hi Tristan and Keir and all,
> 
> Thanks for your idea and comments.
> I will remake and resend these patches in the following command syntax. 
> 
>  xm trigger <Domain> <VCPU> <init|reset|nmi>
 xm trigger <Domain> <init|reset|nmi> [VCPU]
is slightly better.  By default VCPU is 0.

Tristan.

Re: Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windowscrashdump support

[Masaki Kanno]

>On Wed, Jan 24, 2007 at 02:27:42PM +0900, Masaki Kanno wrote:
>[...]
>> Hi Tristan and Keir and all,
>> 
>> Thanks for your idea and comments.
>> I will remake and resend these patches in the following command syntax. 
>> 
>>  xm trigger <Domain> <VCPU> <init|reset|nmi>
> xm trigger <Domain> <init|reset|nmi> [VCPU]
>is slightly better.  By default VCPU is 0.

Okay, I will do that.

 Kan