RE: [Xen-ia64-devel][Patch]Add two PAL calls which fixSMPwindowsinstallation crashing bug
Hi Kouya and Tristan: I still have a question. After 11.XEN stops the vcpu, APs wait in Xen, how does BSP wake up them again? I don't think BSP will send an IPI to them again. In windows, seems BSP will wait a very short time for AP waking up. Whiles APs waked up, they will fall into a loop to wait another times waking up by BSP. But this time, BSP use memory semaphore to do that but not an IPI. En, maybe something I lost, hope your comments. Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kouya SHIMURA Sent: 2007年4月5日 13:52 To: Tristan Gingold Cc: xen-ia64-devel Subject: Re: [Xen-ia64-devel][Patch]Add two PAL calls which fixSMPwindowsinstallation crashing bug Tristan Gingold writes: In 10, I don't understand why the special SAL_XEN_SAL_RETURN is necessary instead of PAL_HALT. The difference is test_and_set_bit() or set_bit(). I think a vcpu with VCPU_down state never be at this point. Besides calling vcpu_sleep_no_sync() with VCPU_down state seems to be harmless. Humm, to be discussed: Although the implementation may be almost the same, I think the semantic is not. After SAL_XEN_SAL_RETURN, the processor can be awaken only by a rendez-vous. Its state is reset. After PAL_HALT, the processor can be awaken by an IPI. Its state is preserved. Tristan. I see. For example, preserving a vcpu context is unnecessary after SAL_XEN_SAL_RETURN for save/restore of a domain. Thanks, Kouya ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] fix xm dump-core with vti domain
fix xm dump-core with VT-i domain.
Share privregs with domain and assign it to pseudo physical address space
as para virtualized domain.
This patch should resolve bug #976.
Akio, could you confirm it and close the bug report?
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1175755484 -32400
# Node ID 87bbc448daccd04dfe6d4b7c6e9052165fbd847b
# Parent f378c424e0ced4cbc584e5c6125d065f1cc05d0c
fix xm dump-core domVTi.
Share privregs with domain and assign it to pseudo physical address space
as para virtualized domain.
PATCHNAME: fix_xm_dump_core_domvti
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r f378c424e0ce -r 87bbc448dacc tools/libxc/xc_core_ia64.c
--- a/tools/libxc/xc_core_ia64.c Tue Apr 03 13:04:51 2007 -0600
+++ b/tools/libxc/xc_core_ia64.c Thu Apr 05 15:44:44 2007 +0900
@@ -93,6 +93,7 @@ memory_map_get_old_hvm(int xc_handle, xc
{IO_PAGE_START, IO_PAGE_SIZE},
{STORE_PAGE_START, STORE_PAGE_SIZE},
{BUFFER_IO_PAGE_START, BUFFER_IO_PAGE_SIZE},
+{BUFFER_PIO_PAGE_START, BUFFER_PIO_PAGE_SIZE},
{GFW_START, GFW_SIZE},
};
const unsigned int nr_gfw_map = sizeof(gfw_map)/sizeof(gfw_map[0]);
diff -r f378c424e0ce -r 87bbc448dacc xen/arch/ia64/vmx/vmx_init.c
--- a/xen/arch/ia64/vmx/vmx_init.c Tue Apr 03 13:04:51 2007 -0600
+++ b/xen/arch/ia64/vmx/vmx_init.c Thu Apr 05 15:44:44 2007 +0900
@@ -301,6 +301,7 @@ vmx_final_setup_guest(struct vcpu *v)
ASSERT(vpd);
v-arch.privregs = (mapped_regs_t *)vpd;
+ vcpu_share_privregs_with_guest(v);
vpd-vpd_low.virt_env_vaddr = vm_buffer;
/* Per-domain vTLB and vhpt implementation. Now vmx domain will stick
diff -r f378c424e0ce -r 87bbc448dacc xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.c Tue Apr 03 13:04:51 2007 -0600
+++ b/xen/arch/ia64/xen/domain.c Thu Apr 05 15:44:44 2007 +0900
@@ -446,22 +446,12 @@ int vcpu_initialise(struct vcpu *v)
return 0;
}
-int vcpu_late_initialise(struct vcpu *v)
+void vcpu_share_privregs_with_guest(struct vcpu *v)
{
struct domain *d = v-domain;
- int rc, order, i;
-
- if (HAS_PERVCPU_VHPT(d)) {
- rc = pervcpu_vhpt_alloc(v);
- if (rc != 0)
- return rc;
- }
-
- /* Create privregs page. */
- order = get_order_from_shift(XMAPPEDREGS_SHIFT);
- v-arch.privregs = alloc_xenheap_pages(order);
- BUG_ON(v-arch.privregs == NULL);
- memset(v-arch.privregs, 0, 1 XMAPPEDREGS_SHIFT);
+ int i;
+ int order = get_order_from_shift(XMAPPEDREGS_SHIFT);
+
for (i = 0; i (1 order); i++)
share_xen_page_with_guest(virt_to_page(v-arch.privregs) + i,
d, XENSHARE_writable);
@@ -474,6 +464,25 @@ int vcpu_late_initialise(struct vcpu *v)
for (i = 0; i XMAPPEDREGS_SIZE; i += PAGE_SIZE)
assign_domain_page(d, IA64_XMAPPEDREGS_PADDR(v-vcpu_id) + i,
virt_to_maddr(v-arch.privregs + i));
+}
+
+int vcpu_late_initialise(struct vcpu *v)
+{
+ struct domain *d = v-domain;
+ int rc, order;
+
+ if (HAS_PERVCPU_VHPT(d)) {
+ rc = pervcpu_vhpt_alloc(v);
+ if (rc != 0)
+ return rc;
+ }
+
+ /* Create privregs page. */
+ order = get_order_from_shift(XMAPPEDREGS_SHIFT);
+ v-arch.privregs = alloc_xenheap_pages(order);
+ BUG_ON(v-arch.privregs == NULL);
+ memset(v-arch.privregs, 0, 1 XMAPPEDREGS_SHIFT);
+ vcpu_share_privregs_with_guest(v);
return 0;
}
diff -r f378c424e0ce -r 87bbc448dacc xen/include/asm-ia64/domain.h
--- a/xen/include/asm-ia64/domain.h Tue Apr 03 13:04:51 2007 -0600
+++ b/xen/include/asm-ia64/domain.h Thu Apr 05 15:44:44 2007 +0900
@@ -21,6 +21,7 @@ extern void domain_relinquish_resources(
extern void domain_relinquish_resources(struct domain *);
struct vcpu;
extern void relinquish_vcpu_resources(struct vcpu *v);
+extern void vcpu_share_privregs_with_guest(struct vcpu *v);
extern int vcpu_late_initialise(struct vcpu *v);
/* given a current domain metaphysical address, return the physical address */
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] fix xm dump-core with vti domain
Hi, Isaku Thank you for your work! I'll check it and close bugzilla. Best Regards, Akio Takebe fix xm dump-core with VT-i domain. Share privregs with domain and assign it to pseudo physical address space as para virtualized domain. This patch should resolve bug #976. Akio, could you confirm it and close the bug report? -- yamahata ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][Patch]Add two PAL calls which fixSMPwindowsinstallation crashing bug
Quoting Zhang, Xing Z [EMAIL PROTECTED]: Hi Kouya and Tristan: I still have a question. After 11.XEN stops the vcpu, APs wait in Xen, how does BSP wake up them again? I don't think BSP will send an IPI to them again. It should. That's the method to awake it. In windows, seems BSP will wait a very short time for AP waking up. Whiles APs waked up, they will fall into a loop to wait another times waking up by BSP. But this time, BSP use memory semaphore to do that but not an IPI. En, maybe something I lost, hope your comments. I do not fully understand the issue. Did the APs returned to SAL ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][Patch]Add two PAL calls which fixSMPwindowsinstallation crashing bug
Hi Wing, According to SAL specification 3.2.5 OS_OOT_RENDEZ, If OS_BOOT_RENDEZ returns a processor to the SAL using BR0, SAL will re-enter the spin loop awaiting a wake-up by the BSP. I guess that the windows installer uses only two cpus. The other cpus kill themselves and never be revived (until reboot). I have no idea why the other cpus are waken up once... Generally speaking, too many cpus might be useless for installing OS. Thanks, Kouya Zhang, Xing Z writes: Hi Kouya and Tristan: I still have a question. After 11.XEN stops the vcpu, APs wait in Xen, how does BSP wake up them again? I don't think BSP will send an IPI to them again. In windows, seems BSP will wait a very short time for AP waking up. Whiles APs waked up, they will fall into a loop to wait another times waking up by BSP. But this time, BSP use memory semaphore to do that but not an IPI. En, maybe something I lost, hope your comments. Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kouya SHIMURA Sent: 2007
RE: [Xen-ia64-devel][Patch]Add two PAL calls which fixSMPwindowsinstallation crashing bug
But this time, BSP use memory semaphore to do that but not an IPI. En, maybe something I lost, hope your comments. I do not fully understand the issue. Did the APs returned to SAL ? If my memory is right, it seems loop in OS. I will check it again in native. Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 2007年4月5日 15:41 To: Zhang, Xing Z Cc: Kouya SHIMURA; Tristan Gingold; xen-ia64-devel Subject: RE: [Xen-ia64-devel][Patch]Add two PAL calls which fixSMPwindowsinstallation crashing bug Quoting Zhang, Xing Z [EMAIL PROTECTED]: Hi Kouya and Tristan: I still have a question. After 11.XEN stops the vcpu, APs wait in Xen, how does BSP wake up them again? I don't think BSP will send an IPI to them again. It should. That's the method to awake it. In windows, seems BSP will wait a very short time for AP waking up. Whiles APs waked up, they will fall into a loop to wait another times waking up by BSP. But this time, BSP use memory semaphore to do that but not an IPI. En, maybe something I lost, hope your comments. I do not fully understand the issue. Did the APs returned to SAL ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Fix typo in xen/arch/ia64/linux-xen/perfmon.c
Hi all,
I found the disunity of error messages and typo in perfmon.c.
This patch fixes it.
Thanks,
KAZ
Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED]
diff -r f378c424e0ce xen/arch/ia64/linux-xen/perfmon.c
--- a/xen/arch/ia64/linux-xen/perfmon.c Tue Apr 03 13:04:51 2007 -0600
+++ b/xen/arch/ia64/linux-xen/perfmon.c Thu Apr 05 17:03:33 2007 +0900
@@ -7471,8 +7471,8 @@ xenpfm_context_load(XEN_GUEST_HANDLE(pfa
spin_unlock(xenpfm_context_lock);
for_each_online_cpu(cpu) {
if (arg.error[cpu]) {
- gdprintk(XENLOG_INFO, %s: error %d cpu %d\n,
-__func__, error, cpu);
+ gdprintk(XENLOG_INFO, %s: cpu %d error %d\n,
+__func__, cpu, arg.error[cpu]);
error = arg.error[cpu];
}
}
@@ -7518,8 +7518,8 @@ xenpfm_context_unload(void)
spin_unlock(xenpfm_context_lock);
for_each_online_cpu(cpu) {
if (arg.error[cpu]) {
- gdprintk(XENLOG_INFO, %s: error %d cpu %d\n,
-__func__, error, cpu);
+ gdprintk(XENLOG_INFO, %s: cpu %d error %d\n,
+__func__, cpu, arg.error[cpu]);
error = arg.error[cpu];
}
}
@@ -7699,7 +7699,7 @@ xenpfm_start_stop_locked(int is_start)
local_irq_restore(flags);
for_each_online_cpu(cpu) {
- if (!arg.error[cpu]) {
+ if (arg.error[cpu]) {
gdprintk(XENLOG_INFO, %s: cpu %d error %d\n,
__func__, cpu, arg.error[cpu]);
error = arg.error[cpu];
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Problem with xen-3.0.4_1-src.tgz compilation on ia64
Hi, Very shortly: make world (...) gcc -O2 -fomit-frame-pointer -DNDEBUG -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -mconstant-gp -O2 -fomit-frame-pointer -D__KERNEL__ -iwithprefix include -I/usr/src/xen-3.0.4_1-src/xen/include -I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64 -I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64/linux -I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64/linux-xen -I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64/linux-null -I/usr/src/xen-3.0.4_1-src/xen/arch/ia64/linux -I/usr/src/xen-3.0.4_1-src/xen/arch/ia64/linux-xen -DIA64 -DXEN -DLINUX_2_6 -ffixed-r13 -mfixed-range=f2-f5,f12-f127 -g -DCONFIG_XEN_IA64_EXPOSE_P2M -DCONFIG_XEN_IA64_PERVCPU_VHPT -DCONFIG_XEN_IA64_TLB_TRACK -DCONFIG_XEN_IA64_TLBFLUSH_CLOCK -g -D__XEN__ -c domain.c -o domain.o domain.c:871: error: conflicting types for 'elf_sanity_check' /usr/src/xen-3.0.4_1-src/xen/include/xen/elf.h:529: error: previous declaration of 'elf_sanity_check' was here make[6]: *** [domain.o] Error 1 make[6]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen/arch/ia64/xen' make[5]: *** [xen/built_in.o] Error 2 make[5]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen/arch/ia64' make[4]: *** [/usr/src/xen-3.0.4_1-src/xen/arch/ia64/built_in.o] Error 2 make[4]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen/arch/ia64' make[3]: *** [/usr/src/xen-3.0.4_1-src/xen/xen] Error 2 make[3]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen' make[2]: *** [install] Error 2 make[2]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen' make[1]: *** [install-xen] Error 2 make[1]: Leaving directory `/usr/src/xen-3.0.4_1-src' make: *** [world] Error 2 ii libc6.1 2.3.6.ds1-13 GNU C Library: Shared libraries ii libc6.1-dev 2.3.6.ds1-13 GNU C Library: Development Libraries and Hea ii gcc 4.1.1-15 The GNU C compiler ii gcc-3.3 3.3.6-15 The GNU C compiler ii gcc-3.3-base 3.3.6-15 The GNU Compiler Collection (base package) ii gcc-4.0 4.0.2-5 The GNU C compiler ii gcc-4.0-base 4.0.2-5 The GNU Compiler Collection (base package) ii gcc-4.1 4.1.1-21 The GNU C compiler ii gcc-4.1-base 4.1.1-21 The GNU Compiler Collection (base package) ii libgcc1 4.1.1-21 GCC support library ii automake1.4 1.4-p6-12 A tool for generating GNU Standards-complian ii make 3.81-3 The GNU version of the make utility. ii makedev 2.3.1-83 creates device files in /dev Linux xxx 2.6.15.1 #8 SMP Sat Jan 28 02:59:42 CET 2006 ia64 GNU/Linux Thanks! -- Radosław Antoniuk ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Problem with xen-3.0.4_1-src.tgz compilation onia64
Hi, Radek
I have never try xen-3.0.4_1_src,
bt if you modify domain.c like the below, you can compile it.
--- xen/arch/ia64/xen/domain.c.orig 2007-04-05 20:26:43.0 +0900
+++ xen/arch/ia64/xen/domain.c 2007-04-05 20:26:58.0 +0900
@@ -867,7 +867,7 @@ int shadow_mode_control(struct domain *d
#endif
// see arch/x86/xxx/domain_build.c
-int elf_sanity_check(Elf_Ehdr *ehdr)
+int elf_sanity_check(const Elf_Ehdr *ehdr)
{
if (!(IS_ELF(*ehdr)))
{
Best Regards,
Akio Takebe
Hi,
Very shortly:
make world
(...)
gcc -O2 -fomit-frame-pointer -DNDEBUG -std=gnu99 -Wall
-Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement
-nostdinc -fno-builtin -fno-common -fno-strict-aliasing -mconstant-gp
-O2 -fomit-frame-pointer -D__KERNEL__ -iwithprefix include
-I/usr/src/xen-3.0.4_1-src/xen/include
-I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64
-I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64/linux
-I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64/linux-xen
-I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64/linux-null
-I/usr/src/xen-3.0.4_1-src/xen/arch/ia64/linux
-I/usr/src/xen-3.0.4_1-src/xen/arch/ia64/linux-xen -DIA64 -DXEN
-DLINUX_2_6 -ffixed-r13 -mfixed-range=f2-f5,f12-f127 -g
-DCONFIG_XEN_IA64_EXPOSE_P2M -DCONFIG_XEN_IA64_PERVCPU_VHPT
-DCONFIG_XEN_IA64_TLB_TRACK -DCONFIG_XEN_IA64_TLBFLUSH_CLOCK -g
-D__XEN__ -c domain.c -o domain.o
domain.c:871: error: conflicting types for 'elf_sanity_check'
/usr/src/xen-3.0.4_1-src/xen/include/xen/elf.h:529: error: previous
declaration of 'elf_sanity_check' was here
make[6]: *** [domain.o] Error 1
make[6]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen/arch/ia64/xen'
make[5]: *** [xen/built_in.o] Error 2
make[5]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen/arch/ia64'
make[4]: *** [/usr/src/xen-3.0.4_1-src/xen/arch/ia64/built_in.o] Error 2
make[4]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen/arch/ia64'
make[3]: *** [/usr/src/xen-3.0.4_1-src/xen/xen] Error 2
make[3]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen'
make[1]: *** [install-xen] Error 2
make[1]: Leaving directory `/usr/src/xen-3.0.4_1-src'
make: *** [world] Error 2
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][Patch]Add two PAL calls which fix SMPwindowsinstallation crashing bug
Hi Kouya and Tristan: After tracing native windows boot sequence, I think these steps which Kouya listed are right. After stage 5, AP will be waked up at guest_rendez. Subsequent stages as below: 1. The AP call a function -- assume it as funA. Before that, AP will save b0 register. 2. AP loop in the funA. 3. BSP checks whether AP waking up successful. 4. If success, AP comes back from funA, then goes to a normal way(so the b0 value which saved before is futility). At this way, the AP boot up successful. 5. If failed, AP comes back from funA and restores b0 value. Then return to b0. At this way, the AP boot up failed and reset CR register subsequently. Compared with VTI, native windows write 0x40 to cr.pta rather than 0x0. At last, the AP will come back to SAL spin loop again. The loop is the same as previous one.( in EFI shell stage). So the BSP only sends once IPI to wake up an AP. If an AP waking up failed, it would loop in SAL through returning to b0 and would never get an awakening IPI from BSP again. Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation -Original Message- From: Kouya SHIMURA [mailto:[EMAIL PROTECTED] Sent: 2007年4月5日 12:33 To: [EMAIL PROTECTED] Cc: Alex Williamson; Zhang, Xing Z; xen-ia64-devel; Xu, Anthony Subject: RE: [Xen-ia64-devel][Patch]Add two PAL calls which fix SMPwindowsinstallation crashing bug Hi Tristan, Alex, Wing, [EMAIL PROTECTED] writes: IMHO the Intel GFW can do all this work, there is no needs to do it in the hypervisor. I read Tristan's GFW roughly. It seem to be already resolved in Tristan's GFW. The following is my understanding. GFW has a stub function SalBootRendezStub() beforehand. 1. GFW issues SAL_SET_VECTORS(SAL_VECTOR_OS_BOOT_RENDEZ, SalBootRendezStub) in very early stage. 2. GOS(Guest OS) is invoked ...[GOS running] 3. GOS issues SAL_SET_VECTORS(SAL_VECTOR_OS_BOOT_RENDEZ, guest_rendez) 4. GFW intercepts it. GFW just preserves the value of guest_rendez in private data. (It never be propagated to XEN) ...[GOS running] 5. GOS invokes a vcpu (sends IPI) 6. XEN jumps into SalBootRendezStub() instead of guest_rendez 7. GFW set cr.pta=152 8. GFW jumps to guest_rendez br.call.sptk.many b0=guest_rendez ...[GOS running] 9. GOS return to b0(SAL RETURN). 10. GFW issues SAL_XEN_SAL_RETURN 11. XEN stops the vcpu. I have two comments. In 7, I think initializing cr.pta should be XEN's job. In 10, I don't understand why the special SAL_XEN_SAL_RETURN is necessary instead of PAL_HALT. The difference is test_and_set_bit() or set_bit(). I think a vcpu with VCPU_down state never be at this point. Besides calling vcpu_sleep_no_sync() with VCPU_down state seems to be harmless. Thanks, Kouya ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Problem with xen-3.0.4_1-src.tgz compilation onia64
2007/4/5, Akio Takebe [EMAIL PROTECTED]:
Hi, Radek
I have never try xen-3.0.4_1_src,
bt if you modify domain.c like the below, you can compile it.
--- xen/arch/ia64/xen/domain.c.orig 2007-04-05 20:26:43.0 +0900
+++ xen/arch/ia64/xen/domain.c 2007-04-05 20:26:58.0 +0900
@@ -867,7 +867,7 @@ int shadow_mode_control(struct domain *d
#endif
// see arch/x86/xxx/domain_build.c
-int elf_sanity_check(Elf_Ehdr *ehdr)
+int elf_sanity_check(const Elf_Ehdr *ehdr)
{
if (!(IS_ELF(*ehdr)))
{
Hi!
Indeed it helped.
Shame that it is not in the official source :(
You said that you didn't try to use 3.0.4.
Which would you prefer instead then?
Radek
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Problem with xen-3.0.4_1-src.tgz compilation onia64
2007/4/5, Radek Antoniuk [EMAIL PROTECTED]:
2007/4/5, Akio Takebe [EMAIL PROTECTED]:
Hi, Radek
I have never try xen-3.0.4_1_src,
bt if you modify domain.c like the below, you can compile it.
--- xen/arch/ia64/xen/domain.c.orig 2007-04-05 20:26:43.0 +0900
+++ xen/arch/ia64/xen/domain.c 2007-04-05 20:26:58.0 +0900
@@ -867,7 +867,7 @@ int shadow_mode_control(struct domain *d
#endif
// see arch/x86/xxx/domain_build.c
-int elf_sanity_check(Elf_Ehdr *ehdr)
+int elf_sanity_check(const Elf_Ehdr *ehdr)
{
if (!(IS_ELF(*ehdr)))
{
Hi!
Indeed it helped.
Shame that it is not in the official source :(
You said that you didn't try to use 3.0.4.
Which would you prefer instead then?
Yeah. That is a actual question.
Then the
/usr/src/xen-3.0.4_1-src/linux-2.6.16.33-xen# make
CHK include/linux/version.h
CHK include/linux/compile.h
CHK usr/initramfs_list
CC arch/ia64/xen/../../i386/kernel/pci-dma-xen.o
arch/ia64/xen/../../i386/kernel/pci-dma-xen.c:18:25: error:
asm/swiotlb.h: No such file or directory
make[1]: *** [arch/ia64/xen/../../i386/kernel/pci-dma-xen.o] Error 1
make: *** [arch/ia64/xen] Error 2
In fact there is no such file.
Looks like some patch is not included during the build process or ... ?
--
Radosław Antoniuk
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] fix initial value of cr.pta
The initial value of cr.pta in a vcpu is zero. So a Reserved Register/Field fault is raised if a guest executes the following sequence. mov r2=cr.pta;; ... mov cr.pta=r2 Actually, the windows installer with vcpus=3 crashes due to this issue. -- Kouya Signed-off-by: Kouya Shimura [EMAIL PROTECTED] diff -r f378c424e0ce xen/arch/ia64/xen/vcpu.c --- a/xen/arch/ia64/xen/vcpu.c Tue Apr 03 13:04:51 2007 -0600 +++ b/xen/arch/ia64/xen/vcpu.c Thu Apr 05 17:30:50 2007 +0900 @@ -174,6 +174,8 @@ void vcpu_init_regs(struct vcpu *v) INT_ENABLE_OFFSET(v); VCPU(v, itv) = (1 16); /* timer vector masked */ } + + VCPU(v, pta) = 152; /* pta.size mustn't be 0. the minimum is 15 */ v-arch.domain_itm_last = -1L; } ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Problem with xen-3.0.4_1-src.tgz compilation onia64
Hi, Radek Hi! Indeed it helped. Shame that it is not in the official source :( You said that you didn't try to use 3.0.4. Which would you prefer instead then? Yeah. That is a actual question. Then the /usr/src/xen-3.0.4_1-src/linux-2.6.16.33-xen# make CHK include/linux/version.h CHK include/linux/compile.h CHK usr/initramfs_list CC arch/ia64/xen/../../i386/kernel/pci-dma-xen.o arch/ia64/xen/../../i386/kernel/pci-dma-xen.c:18:25: error: asm/swiotlb.h: No such file or directory make[1]: *** [arch/ia64/xen/../../i386/kernel/pci-dma-xen.o] Error 1 make: *** [arch/ia64/xen] Error 2 In fact there is no such file. Looks like some patch is not included during the build process or ... ? Hm. You apply the following patch. And if you do make kdelete, make kernels, you must compile it. http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/8af3df2f4b01 When you install it, you see the following documents. xen/arch/ia64/tools/README.xenia64 Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Problem with xen-3.0.4_1-src.tgz compilation onia64
Hi, Radek
I always use xen-ia64-unstable.hg because I develop it.
Current xen-ia64 is very stable.
And you may use RHEL5.
Best Regards,
Akio Takebe
2007/4/5, Akio Takebe [EMAIL PROTECTED]:
Hi, Radek
I have never try xen-3.0.4_1_src,
bt if you modify domain.c like the below, you can compile it.
--- xen/arch/ia64/xen/domain.c.orig 2007-04-05 20:26:43.0 +0900
+++ xen/arch/ia64/xen/domain.c 2007-04-05 20:26:58.0 +0900
@@ -867,7 +867,7 @@ int shadow_mode_control(struct domain *d
#endif
// see arch/x86/xxx/domain_build.c
-int elf_sanity_check(Elf_Ehdr *ehdr)
+int elf_sanity_check(const Elf_Ehdr *ehdr)
{
if (!(IS_ELF(*ehdr)))
{
Hi!
Indeed it helped.
Shame that it is not in the official source :(
You said that you didn't try to use 3.0.4.
Which would you prefer instead then?
Radek
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] fix xm dump-core with vti domain
Hi, Isaku By using this patch, we can get dump-core of HVM domain well. Thanks again! I close bugzilla. Best Regards, Akio Takebe Hi, Isaku Thank you for your work! I'll check it and close bugzilla. Best Regards, Akio Takebe fix xm dump-core with VT-i domain. Share privregs with domain and assign it to pseudo physical address space as para virtualized domain. This patch should resolve bug #976. Akio, could you confirm it and close the bug report? -- yamahata ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][Patch]Add two PAL calls which fix SMPwindowsinstallation crashing bug
Agree, Tristan's GFW can resolve installation issue and implement cpu hotplug as well, Anthony -Original Message- From: Kouya SHIMURA [mailto:[EMAIL PROTECTED] Sent: 2007年4月5日 12:33 To: [EMAIL PROTECTED] Cc: Alex Williamson; Zhang, Xing Z; xen-ia64-devel; Xu, Anthony Subject: RE: [Xen-ia64-devel][Patch]Add two PAL calls which fix SMPwindowsinstallation crashing bug Hi Tristan, Alex, Wing, [EMAIL PROTECTED] writes: IMHO the Intel GFW can do all this work, there is no needs to do it in the hypervisor. I read Tristan's GFW roughly. It seem to be already resolved in Tristan's GFW. The following is my understanding. GFW has a stub function SalBootRendezStub() beforehand. 1. GFW issues SAL_SET_VECTORS(SAL_VECTOR_OS_BOOT_RENDEZ, SalBootRendezStub) in very early stage. 2. GOS(Guest OS) is invoked ...[GOS running] 3. GOS issues SAL_SET_VECTORS(SAL_VECTOR_OS_BOOT_RENDEZ, guest_rendez) 4. GFW intercepts it. GFW just preserves the value of guest_rendez in private data. (It never be propagated to XEN) ...[GOS running] 5. GOS invokes a vcpu (sends IPI) 6. XEN jumps into SalBootRendezStub() instead of guest_rendez 7. GFW set cr.pta=152 8. GFW jumps to guest_rendez br.call.sptk.many b0=guest_rendez ...[GOS running] 9. GOS return to b0(SAL RETURN). 10. GFW issues SAL_XEN_SAL_RETURN 11. XEN stops the vcpu. I have two comments. In 7, I think initializing cr.pta should be XEN's job. In 10, I don't understand why the special SAL_XEN_SAL_RETURN is necessary instead of PAL_HALT. The difference is test_and_set_bit() or set_bit(). I think a vcpu with VCPU_down state never be at this point. Besides calling vcpu_sleep_no_sync() with VCPU_down state seems to be harmless. Thanks, Kouya ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch][RFC] Auto setup serial console on PRIMEQUEST
On Thu, 2007-04-05 at 10:44 +0900, Akio Takebe wrote: Hi, I make a patch to use serial console without setting bootparameter on PQ. 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 xm dump-core with vti domain
On Thu, 2007-04-05 at 15:52 +0900, Isaku Yamahata wrote: fix xm dump-core with VT-i domain. Share privregs with domain and assign it to pseudo physical address space as para virtualized domain. This patch should resolve bug #976. 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 initial value of cr.pta
On Thu, 2007-04-05 at 18:07 +0900, Kouya SHIMURA wrote: The initial value of cr.pta in a vcpu is zero. So a Reserved Register/Field fault is raised if a guest executes the following sequence. mov r2=cr.pta;; ... mov cr.pta=r2 Actually, the windows installer with vcpus=3 crashes due to this issue. 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 typo in xen/arch/ia64/linux-xen/perfmon.c
On Thu, 2007-04-05 at 18:22 +0900, SUZUKI Kazuhiro wrote: Hi all, I found the disunity of error messages and typo in perfmon.c. This patch fixes 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] Xen/IA64 Healthiness Report -Cset#14712
Xen/IA64 Healthiness Report All the cases in this Cset have passed. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core) PAL version: 8.47 Service OS: RHEL4u3 IA64 SMP with 2 VCPUs VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 14712:5d9ab2d06709 Xen Schedule: credit VTI Guest Firmware Flash.fd.2006.12.01 MD5: 09a224270416036a8b4e6f8496e97854 Summary Test Report: - Total cases: 17 Passed: 17 Failed: 0 Case Name Status Case Description Pvpass Four_SMPVTI_Coexist pass 4 VTI (mem=256, vcpus=2) Two_UP_VTI_Co pass 2 UP_VTI (mem=256) One_UP_VTI pass 1 UP_VTI (mem=256) One_UP_XenU pass 1 UP_xenU(mem=256) SMPVTI_LTP pass VTI (vcpus=4, mem=512) run LTP SMPVTI_and_SMPXenU pass 1 VTI + 1 xenU (mem=256 vcpus=2) Two_SMPXenU_Coexist pass 2 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_Network pass 1 XenU (vcpus=2) and 'ping' One_SMP_XenU pass 1 SMP xenU (vcpus=2) One_SMP_VTI pass 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: - 14708:f378c424e0ce Best Regards Liuqing ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] include/xen/xencomm.h's copy_field_{to, from}_guest() (PPC, IA64)
On Thu, Apr 05, 2007 at 12:16:38PM +0100, Jan Beulich wrote: While the header is only being used by PPC, aren't these two macros broken, i.e. shouldn't the match the ia64 variants in using the structure base address from the handle and passing just _off as last argument to xencomm_copy_...()? Also, what is the reason for ia64 to cook its own rather than including the shared one? The ia64 xencomm development stragety was that adopt xencomm first, then consolidate it. But the consolication hasn't been achieved yet. The PPC developers kindly arranged the common code already so that the rest task is left to the IA64 developers. However the task seems to be low priority. (Others may have different thoughts, though) Do you think it's important or want to do it? -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
