Xen devel - Jan 2007 - [Xen-ia64-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support

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



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

[1/5] Xen common side. 



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

[2/5] Xen arch_ia64 side. 



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

[3/5] Linux arch_ia64 side. 



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

[4/5] Tools common side. 



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

[5/5] Tools arch_ia64 side. 



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

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



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

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

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

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



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

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



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

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.


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

>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



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

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

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

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


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

>>> 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



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

>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



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

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.

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

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


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

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.

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

>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



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

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.

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

>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



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