Re: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support
On 23/1/07 7:47 am, Jürgen Groß [EMAIL PROTECTED] 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
[Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support
On 23/1/07 2:40 am, Masaki Kanno [EMAIL PROTECTED] 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
Re: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support
On Tue, Jan 23, 2007 at 08:06:23AM +, Keir Fraser wrote: On 23/1/07 2:40 am, Masaki Kanno [EMAIL PROTECTED] 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-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support
On 23/1/07 2:40 am, Masaki Kanno [EMAIL PROTECTED] 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
[Xen-ia64-devel] [PV-on-HVM] Hypercall optimizations
Hi All, We tested pv-on-hvm. But pv-on-hvm doesn't work by Hypercall optimizations. ・xen-ia64-unstable.hg : 13367 [IA64] Hypercall optimizations If we load xen-platform-pci.ko, the following errors occur. # insmod xen-platform-pci.ko xen_platform_pci: Unknown symbol __hypercall insmod: error inserting 'xen-platform-pci.ko': -1 Unknown symbol in module It is necessary to export functio of __ hypercall() in unmodified_drivers. However, function of __hypercall() is defined by assembler code. How should we define function of __hypercall() in unmodified_drivers? Then, how should export symbol of __hypercall()? Best Regards, -- Takanori Kasai ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] Add netfornt tx_queue_len
The patch modifis common-code, not ia64 specific. You should send it to xen-devel with Cc to xen-ia64-devel. On Tue, Jan 23, 2007 at 03:26:41PM +0900, Tomonari Horikoshi wrote: Content-Description: Mail message body Hi all. I mistook sending mail. I send it again. -- Hi all. When I executed netperf by a short message of UDP, PV domain issued Call trace. I think that GrantEntry was filled with a lot of messages processings. This problem is generated in IA64 only. I corrected to check number of unprocessing queue tx_queue_len before Grant was filled. Is there other a good correction? # ./netperf -t UDP_STREAM -H 10.34.179.101 -l 3 -- -m 10 -M 10 netperf[2474]: bugcheck! 0 [1] Modules linked in: Pid: 2474, CPU 0, comm: netperf psr : 1010081a2010 ifs : 8b9b ip : [a001006c9ce0] Not tainted ip is at network_start_xmit+0xa00/0xe40 unat: pfs : 8b9b rsc : 000b rnat: bsps: pr : 010468241566 ldrs: ccv : fpsr: 0009804c8a70033f csd : ssd : Best regards, Tomonari Horikoshi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windows crashdump support
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
Re: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windowscrashdump support
On Tue, Jan 23, 2007 at 08:06:23AM +, Keir Fraser wrote: On 23/1/07 2:40 am, Masaki Kanno [EMAIL PROTECTED] 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
Re: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windowscrashdump support
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-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] fix oops message from timer_interrupt on VTI domain
On Tue, 2007-01-23 at 09:36 +0900, Atsushi SAKAI wrote:
diff -r 91be8436952d xen/arch/ia64/vmx/vlsapic.c
--- a/xen/arch/ia64/vmx/vlsapic.c Wed Jan 10 10:37:41 2007 -0700
+++ b/xen/arch/ia64/vmx/vlsapic.c Tue Jan 23 09:21:13 2007 +0900
@@ -59,7 +59,7 @@ extern void vmx_reflect_interruption(u64
u64 vector, REGS *regs);
static void update_last_itc(vtime_t *vtm, uint64_t cur_itc)
{
-vtm-last_itc = cur_itc;
+vtm-last_itc = cur_itc + 1;
}
/*
In theory, I think this is probably fine. But wouldn't it make more
sense to have the caller do the increment? Something like:
update_last_itc(vtm, VCPU(vcpu, itm) + 1);
Preferably with a nice comment describing the condition that + 1 is
trying to avoid. 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: [Xen-ia64-devel] [PATCH] fix oops message from timer_interrupt on VTI domain
Atsushi SAKAI wrote: [Mon Jan 22 2007, 07:36:55PM EST] Oops: timer tick before it's due (itc=ed98bb5849,itm=ed98bb5849) Oops: timer tick before it's due (itc=f20bca8ca3,itm=f20bca8ca3) Oops: timer tick before it's due (itc=f4ea4e2b32,itm=f4ea4e2b32) ... These oops messages are generated because timer_interrupt checks the condition itc itm. Is that the right comparison though? itc isn't guaranteed to return different values on subsequent fetches, and the interrupt is generated when itc == itm, right? So shouldn't the condition be itc = itm? Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] fix oops message from timer_interrupt on VTI domain
On Tue, 2007-01-23 at 16:44 -0500, Aron Griffis wrote: Atsushi SAKAI wrote: [Mon Jan 22 2007, 07:36:55PM EST] Oops: timer tick before it's due (itc=ed98bb5849,itm=ed98bb5849) Oops: timer tick before it's due (itc=f20bca8ca3,itm=f20bca8ca3) Oops: timer tick before it's due (itc=f4ea4e2b32,itm=f4ea4e2b32) ... These oops messages are generated because timer_interrupt checks the condition itc itm. Is that the right comparison though? itc isn't guaranteed to return different values on subsequent fetches, and the interrupt is generated when itc == itm, right? So shouldn't the condition be itc = itm? Good point. With the slower ITC on a Montecito system, I don't know if anything would prevent you hitting the interrupt handler when itc == itm. Perhaps a Montecito fix for Linux-ia64 to use time_after_eq() would eliminate this problem. 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: [Xen-ia64-devel][Patch] Clean patch (clean VLIDATE_VT)
On Thu, 2007-01-18 at 16:35 +0800, Zhang, Xing Z wrote: It’s not be defined, so clean it. Applied. 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: [Xen-ia64-devel][PATCH] don't panic dom0 if there is not enough memory to create guest
On Thu, 2007-01-18 at 18:00 +0800, Zhang, Xing Z wrote: When there is not enough memory to create a domain, we not need panic domain0. Just prevent it from crating. Applied. 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: [Xen-ia64-devel][PATCH]Implement eager save, lazy restore FPalgorithm
On Thu, 2007-01-18 at 23:46 +0800, Xu, Anthony wrote: I didn't consider VCPU migration in previous patch. This patch fixed this. Tested by running KB on two VTI domain with two VCPUs each. This version seems to work fine. Applied. 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: [Xen-ia64-devel] [Patch 2/2] improve calltarce
On Fri, 2007-01-19 at 12:48 +0900, Akio Takebe wrote: Hi, I improve CallTrace at the time of pushing INIT button. This improve to support calltrace of all vcpu. Applied. 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: [Xen-ia64-devel][PATCH] Fix Xen crash when creating VTI in some machines.
On Fri, 2007-01-19 at 16:37 +0800, Zhang, Xing Z wrote: Xend will do a hypercall to destory domain when creating VTI guest fail. If is_vti not be set at this point, HV will call relinquish_vcpu_resource() which belong to domU. It may try to free a NULL pointer, so dom0 crash. This patch fix it. Applied. 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
[Xen-ia64-devel] [PATCH] Add netfornt tx_queue_len
Thank you for your comment. ( - Isaku Yamahata) Isaku Yamahata wrote:-- Sent:Tue, 23 Jan 2007 22:29:47 +0900 Subject: Re: [Xen-ia64-devel] [PATCH] Add netfornt tx_queue_len The patch modifis common-code, not ia64 specific. You should send it to xen-devel with Cc to xen-ia64-devel. -- Hi all. When I executed netperf by a short message of UDP, PV domain and PV-on-HVM driver issued Call trace. I think that GrantEntry was filled with a lot of messages processings. This problem is generated in IA64 only. Probably, I think that I am the following problems. In IA64 NET_TX_RING_SIZE 1024, NR_GRANT_ENTRIES 2048 In x86 NET_TX_RING_SIZE 256, NR_GRANT_ENTRIES 2048 I corrected to check number of unprocessing queue tx_queue_len before Grant was filled. However, my correction influences x86. Please teach to me in that when there is a better improvement. # ./netperf -t UDP_STREAM -H 10.34.179.101 -l 3 -- -m 10 -M 10 netperf[2474]: bugcheck! 0 [1] Modules linked in: Pid: 2474, CPU 0, comm: netperf psr : 1010081a2010 ifs : 8b9b ip : [a001006c9ce0]Not tainted ip is at network_start_xmit+0xa00/0xe40 unat: pfs : 8b9b rsc : 000b rnat: bsps: pr : 010468241566 ldrs: ccv : fpsr: 0009804c8a70033f csd : ssd : Best regards, Tomonari Horikoshi tx-queue-len-support.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] ptc_ga might not purge vtlb
Hi,
SMP Windows sometimes failed to boot up with BSOD.
After the deep investigation, I found a bug.
If VTLB hasn't been used in region 0,
ptc_ga for other region doesn't purge VTLBs.
Thanks,
Kouya
Signed-off-by: Kouya Shimura [EMAIL PROTECTED]
diff -r 10dd3c907ca7 xen/arch/ia64/vmx/vmmu.c
--- a/xen/arch/ia64/vmx/vmmu.c Tue Jan 23 12:07:02 2007 -0700
+++ b/xen/arch/ia64/vmx/vmmu.c Wed Jan 24 11:12:03 2007 +0900
@@ -574,7 +574,8 @@ static void ptc_ga_remote_func (void *va
mpta = ia64_get_pta();
ia64_set_pta(v-arch.arch_vmx.mpta(~1));
ia64_srlz_d();
-vmx_vcpu_ptc_l(v, REGION_OFFSET(vadr), args-ps);
+vadr = PAGEALIGN(vadr, args-ps);
+thash_purge_entries_remote(v, vadr, args-ps);
VMX(v, vrr[0]) = oldrid;
VMX(v, psbits[0]) = oldpsbits;
ia64_set_rr(0x0,moldrid);
diff -r 10dd3c907ca7 xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Tue Jan 23 12:07:02 2007 -0700
+++ b/xen/arch/ia64/vmx/vtlb.c Wed Jan 24 11:12:03 2007 +0900
@@ -261,7 +261,7 @@ u64 guest_vhpt_lookup(u64 iha, u64 *pte)
* purge software guest tlb
*/
-void vtlb_purge(VCPU *v, u64 va, u64 ps)
+static void vtlb_purge(VCPU *v, u64 va, u64 ps)
{
thash_data_t *cur;
u64 start, curadr, size, psbits, tag, rr_ps, num;
@@ -442,6 +442,15 @@ void thash_purge_entries(VCPU *v, u64 va
vhpt_purge(v, va, ps);
}
+void thash_purge_entries_remote(VCPU *v, u64 va, u64 ps)
+{
+u64 old_va = va;
+va = REGION_OFFSET(va);
+if(vcpu_quick_region_check(v-arch.tc_regions,old_va))
+vtlb_purge(v, va, ps);
+vhpt_purge(v, va, ps);
+}
+
u64 translate_phy_pte(VCPU *v, u64 *pte, u64 itir, u64 va)
{
u64 ps, ps_mask, paddr, maddr;
diff -r 10dd3c907ca7 xen/include/asm-ia64/vmmu.h
--- a/xen/include/asm-ia64/vmmu.h Tue Jan 23 12:07:02 2007 -0700
+++ b/xen/include/asm-ia64/vmmu.h Wed Jan 24 11:12:03 2007 +0900
@@ -271,6 +271,7 @@ extern thash_data_t *thash_find_next_ove
*
*/
extern void thash_purge_entries(struct vcpu *v, u64 va, u64 ps);
+extern void thash_purge_entries_remote(struct vcpu *v, u64 va, u64 ps);
extern void thash_purge_and_insert(struct vcpu *v, u64 pte, u64 itir, u64 ifa,
int type);
/*
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PV-on-HVM] Hypercall optimizations
Hi Kasai, For PV-on-HVM, it needs to implement hypercall stub itself. This stub needs to be implemented by a function call. It is necessary to export functio of __ hypercall() in unmodified_drivers. However, function of __hypercall() is defined by assembler code. I don't quite understand this question. Even __hypercall() is definded by assembler code. It can be exported by using EXPORT_SYMBOL(__hypercall) in some C file. - Anthony Kasai Takanori write on 2007年1月23日 20:23: Hi All, We tested pv-on-hvm. But pv-on-hvm doesn't work by Hypercall optimizations. ・xen-ia64-unstable.hg : 13367 [IA64] Hypercall optimizations If we load xen-platform-pci.ko, the following errors occur. # insmod xen-platform-pci.ko xen_platform_pci: Unknown symbol __hypercall insmod: error inserting 'xen-platform-pci.ko': -1 Unknown symbol in module It is necessary to export functio of __ hypercall() in unmodified_drivers. However, function of __hypercall() is defined by assembler code. How should we define function of __hypercall() in unmodified_drivers? Then, how should export symbol of __hypercall()? Best Regards, ___ 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: [Xen-ia64-devel] [PATCH] ptc_ga might not purge vtlb
Hi kouya, Good catch!!! It is not easy to narrow down this issue. Thanks, - Anthony Kouya SHIMURA write on 2007年1月24日 10:37: Hi, SMP Windows sometimes failed to boot up with BSOD. After the deep investigation, I found a bug. If VTLB hasn't been used in region 0, ptc_ga for other region doesn't purge VTLBs. Thanks, Kouya Signed-off-by: Kouya Shimura [EMAIL PROTECTED] ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] xen might misunderstand a normal page as I/O page
Hi, Hypervisor might misunderstand a normal page as I/O page if a guest OS uses the ig field in the guest VHPT. It seems to be harmless but slightly slow down. Thanks, Kouya Signed-off-by: Kouya Shimura [EMAIL PROTECTED] diff -r 58637a0a7c7e xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Wed Jan 17 21:45:34 2007 -0700 +++ b/xen/arch/ia64/vmx/vtlb.c Wed Jan 24 12:35:55 2007 +0900 @@ -248,6 +248,7 @@ u64 guest_vhpt_lookup(u64 iha, u64 *pte) tnat.nz p6,p7=r9;; (p6) mov %0=1; (p6) mov r9=r0; + (p7) extr.u r9=r9,0,53;; (p7) mov %0=r0; (p7) st8 [%2]=r9;; ssm psr.ic;; ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] xen might misunderstand a normal page asI/O page
Hi Kouya, Can you explain more? How does misunderstanding happen? And how does this patch fix it? Thanks Anthony Kouya SHIMURA write on 2007年1月24日 12:31: Hi, Hypervisor might misunderstand a normal page as I/O page if a guest OS uses the ig field in the guest VHPT. It seems to be harmless but slightly slow down. Thanks, Kouya Signed-off-by: Kouya Shimura [EMAIL PROTECTED] ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windowscrashdump support
On Tue, Jan 23, 2007 at 04:36:57PM +, Keir Fraser wrote: On 23/1/07 16:32, Tristan Gingold [EMAIL PROTECTED] 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
Re: [Xen-ia64-devel][PATCH] don't panic dom0 if there is not enoughmemory to create guest
Hello Zhang,
I understand this is already applied, but I have some minor comments
for the future.
Aron
Zhang, Xing Z wrote: [Thu Jan 18 2007, 09:05:21PM EST]
Content-Description: donnot_panic_dom0_2.patch
When there is not enough memory to create a domain,
we not need panic domain0. Just prevent it from crating.
Signed-off-by, Zhang Xin [EMAIL PROTECTED]
diff -r 58637a0a7c7e xen/arch/ia64/vmx/vmmu.c
--- a/xen/arch/ia64/vmx/vmmu.cWed Jan 17 21:45:34 2007 -0700
+++ b/xen/arch/ia64/vmx/vmmu.cFri Jan 19 01:38:42 2007 +0800
@@ -129,13 +129,16 @@ purge_machine_tc_by_domid(domid_t domid)
#endif
}
-static void init_domain_vhpt(struct vcpu *v)
+static int init_domain_vhpt(struct vcpu *v)
{
struct page_info *page;
void * vbase;
page = alloc_domheap_pages (NULL, VCPU_VHPT_ORDER, 0);
if ( page == NULL ) {
-panic_domain(vcpu_regs(v),No enough contiguous memory for
init_domain_vhpt\n);
+//panic_domain(vcpu_regs(v),No enough contiguous memory for
init_domain_vhpt\n);
+printk(No enough contiguous memory for init_domain_vhpt\n);
There's no need to comment out the panic_domain line. That's what
source control is for! :-) Better to just remove it.
+
+return -1;
}
vbase = page_to_virt(page);
memset(vbase, 0, VCPU_VHPT_SIZE);
@@ -147,18 +150,38 @@ static void init_domain_vhpt(struct vcpu
VHPT(v,cch_sz) = VCPU_VHPT_SIZE - VHPT(v,hash_sz);
thash_init((v-arch.vhpt),VCPU_VHPT_SHIFT-1);
v-arch.arch_vmx.mpta = v-arch.vhpt.pta.val;
-}
-
-
-
-void init_domain_tlb(struct vcpu *v)
+
+return 0;
+}
+
+
+static void free_domain_vhpt(struct vcpu *v)
+{
+struct page_info *page;
+
+if ( v-arch.vhpt.hash) {
+page = virt_to_page(v-arch.vhpt.hash);
+free_domheap_pages(page, VCPU_VHPT_ORDER);
+}
+
+return;
+}
+
+int init_domain_tlb(struct vcpu *v)
{
struct page_info *page;
void * vbase;
-init_domain_vhpt(v);
+
+if ( init_domain_vhpt(v) != 0 )
+goto err;
+
page = alloc_domheap_pages (NULL, VCPU_VTLB_ORDER, 0);
if ( page == NULL ) {
-panic_domain(vcpu_regs(v),No enough contiguous memory for
init_domain_tlb\n);
+//panic_domain(No enough contiguous memory for init_domain_tlb\n);
+printk(No enough contiguous memory for init_domain_tlb\n);
Same here.
+free_domain_vhpt(v);
+
+goto err;
}
vbase = page_to_virt(page);
memset(vbase, 0, VCPU_VTLB_SIZE);
@@ -169,7 +192,12 @@ void init_domain_tlb(struct vcpu *v)
VTLB(v,cch_buf) = (void *)((u64)vbase + VTLB(v,hash_sz));
VTLB(v,cch_sz) = VCPU_VTLB_SIZE - VTLB(v,hash_sz);
thash_init((v-arch.vtlb),VCPU_VTLB_SHIFT-1);
-}
+
+return 0;
+err:
+return -1;
+}
If there's nothing to clean up, IMHO there is no need for goto err.
Instead you could just return the error code directly.
Is there a better error code to use in these cases than -1, for
example -ENOMEM?
+
void free_domain_tlb(struct vcpu *v)
{
@@ -179,10 +207,8 @@ void free_domain_tlb(struct vcpu *v)
page = virt_to_page(v-arch.vtlb.hash);
free_domheap_pages(page, VCPU_VTLB_ORDER);
}
-if ( v-arch.vhpt.hash) {
-page = virt_to_page(v-arch.vhpt.hash);
-free_domheap_pages(page, VCPU_VHPT_ORDER);
-}
+
+free_domain_vhpt(v);
}
/*
diff -r 58637a0a7c7e xen/arch/ia64/vmx/vmx_init.c
--- a/xen/arch/ia64/vmx/vmx_init.cWed Jan 17 21:45:34 2007 -0700
+++ b/xen/arch/ia64/vmx/vmx_init.cThu Jan 18 09:56:06 2007 +0800
@@ -290,7 +290,7 @@ static void vmx_release_assist_channel(s
* Initialize VMX envirenment for guest. Only the 1st vp/vcpu
* is registered here.
*/
-void
+int
vmx_final_setup_guest(struct vcpu *v)
{
vpd_t *vpd;
@@ -305,7 +305,8 @@ vmx_final_setup_guest(struct vcpu *v)
* to this solution. Maybe it can be deferred until we know created
* one as vmx domain */
#ifndef HASH_VHPT
- init_domain_tlb(v);
+ if ( init_domain_tlb(v) != 0 )
+goto err;
#endif
vmx_create_event_channels(v);
@@ -322,6 +323,10 @@ vmx_final_setup_guest(struct vcpu *v)
/* Set up guest 's indicator for VTi domain*/
set_bit(ARCH_VMX_DOMAIN, v-arch.arch_vmx.flags);
+
+return 0;
+err:
+return -1;
}
Same here.
void
diff -r 58637a0a7c7e xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.c Wed Jan 17 21:45:34 2007 -0700
+++ b/xen/arch/ia64/xen/domain.c Thu Jan 18 09:56:06 2007 +0800
@@ -585,8 +585,11 @@ int arch_set_info_guest(struct vcpu *v,
if (test_bit(_VCPUF_initialised, v-vcpu_flags))
return 0;
- if (d-arch.is_vti)
- vmx_final_setup_guest(v);
+ if (d-arch.is_vti){
+ rc = vmx_final_setup_guest(v);
+if ( rc != 0 )
+return rc;
+}
else {
[Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#13472
Xen/IA64 Healthiness Report 1 SMP VTI testing case failed in daily testing progress. But after retesting more than 100 times for this case, we can not reproduce the failure. So just look it as the occasional case. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core) Service OS: RHEL4u3 IA64 SMP with 2 vcpus 1G memory VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 13472:10dd3c907ca7 Xen Schedule: credit VTI Guest Firmware Flash.fd.2006.12.01 MD5: 09a224270416036a8b4e6f8496e97854 Summary Test Report: - Total cases: 16 Passed:16 Failed: 0 Case Name Status Case Description Four_SMPVTI_Coexistpass 4 VTI (mem=256, vcpus=2) Two_UP_VTI_Co pass 2 UP_VTI (mem=256) One_UP_VTIpass1 UP_VTI (mem=256) One_UP_XenU pass1 UP_xenU(mem=256) SMPVTI_LTPpassVTI (vcpus=4, mem=512) run LTP SMPVTI_and_SMPXenU pass 1 VTI + 1 xenU (mem=256 vcpus=2) Two_SMPXenU_Coexistpass2 xenU (mem=256, vcpus=2) One_SMPVTI_4096M pass 1 VTI (vcpus=2, mem=4096M) SMPVTI_Network pass 1 VTI (mem=256,vcpu=2) and 'ping' SMPXenU_Networkpass 1 XenU (vcpus=2) and 'ping' One_SMP_XenU pass 1 SMP xenU (vcpus=2) One_SMP_VTIpass 1 SMP VTI (vcpus=2) SMPVTI_Kernel_Build pass VTI (vcpus=4) and do Kernel Build Four_SMPVTI_Coexist pass 4 VTI domains( mem=256, vcpu=2) SMPVTI_Windows pass SMPVTI windows(vcpu=2) SMPWin_SMPVTI_SMPxenU pass SMPVTI Linux/Windows XenU UPVTI_Kernel_Build pass 1 UP VTI and do kernel build Notes: - The last stable changeset: - 13472:10dd3c907ca7 Thanks, Yongkang ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5][IA64][HVM] Windowscrashdump support
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-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
