[Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#14708
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: 14708:f378c424e0ce 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: - 14679:fc9e2f7920c9 Best Regards Liuqing ___ 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 Alex, Wing,
I revised my patch(return to SAL). What do you think?
This is still dirty since it uses the rest area of HOB.
Is there any other good place for SAL_RETURN_STUB_PADDR?
Thanks,
Kouya
Alex Williamson writes:
Can this be combined with Tristan's approach for HVM vCPU hotplug
that he's implemented in his GFW? Tristan allows hotplugged vCPUs to
return online, which it appears this one does not. It might take
changes to both the Intel GFW and to Xen to make this work. Thanks,
Alex
--
Alex Williamson HP Open Source Linux Org.
diff -r fc9e2f7920c9 tools/libxc/ia64/xc_ia64_hvm_build.c
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c Fri Mar 30 17:18:42 2007 -0600
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c Wed Apr 04 21:17:34 2007 +0900
@@ -73,8 +73,6 @@ xc_get_hvm_param(int handle, domid_t dom
}
#define HOB_SIGNATURE 0x3436474953424f48// HOBSIG64
-#define GFW_HOB_START ((4UL30)-(14UL20))// 4G - 14M
-#define GFW_HOB_SIZE (1UL20) // 1M
typedef struct {
unsigned long signature;
@@ -280,6 +278,7 @@ load_hob(int xc_handle, uint32_t dom, vo
// hob_buf should be page aligned
int hob_size;
int nr_pages;
+unsigned long *code;
hob_size = get_hob_size(hob_buf);
if (hob_size 0) {
@@ -287,12 +286,31 @@ load_hob(int xc_handle, uint32_t dom, vo
return -1;
}
-if (hob_size GFW_HOB_SIZE) {
+if (hob_size GFW_HOB_SIZE - 0x10) {
PERROR(No enough memory for hob data);
return -1;
}
+/*
+ * inject a emulation code for SAL Return state from OS_BOOT_RENDEZ
+ *
+ * 1: mov r28=0x28 // PAL_HALT
+ *break 0x11 // DOMN_PAL_REQUEST
+ *br.many.sptk.few 1
+ */
+code = hob_buf + GFW_HOB_SIZE - 0x10;
+code[0] = 0x2470e011;
+code[1] = 0x40040010;
+
nr_pages = (hob_size + PAGE_SIZE -1) PAGE_SHIFT;
+
+if (nr_pages (GFW_HOB_SIZE PAGE_SHIFT)) {
+// copy the emulation code
+if (xc_ia64_copy_to_domain_pages(xc_handle, dom,
+hob_buf + GFW_HOB_SIZE - PAGE_SIZE,
+(GFW_HOB_START + GFW_HOB_SIZE - PAGE_SIZE) PAGE_SHIFT, 1))
+return -1;
+}
return xc_ia64_copy_to_domain_pages(xc_handle, dom, hob_buf,
GFW_HOB_START PAGE_SHIFT, nr_pages);
diff -r fc9e2f7920c9 xen/arch/ia64/vmx/vlsapic.c
--- a/xen/arch/ia64/vmx/vlsapic.c Fri Mar 30 17:18:42 2007 -0600
+++ b/xen/arch/ia64/vmx/vlsapic.c Wed Apr 04 21:17:34 2007 +0900
@@ -708,6 +708,7 @@ static void vlsapic_write_ipi(VCPU *vcpu
vcpu_init_regs(targ);
targ_regs-cr_iip = d-arch.sal_data-boot_rdv_ip;
targ_regs-r1 = d-arch.sal_data-boot_rdv_r1;
+targ_regs-b0 = SAL_RETURN_STUB_PADDR;
if (test_and_clear_bit(_VPF_down,targ-pause_flags)) {
vcpu_wake(targ);
diff -r fc9e2f7920c9 xen/arch/ia64/xen/fw_emul.c
--- a/xen/arch/ia64/xen/fw_emul.c Fri Mar 30 17:18:42 2007 -0600
+++ b/xen/arch/ia64/xen/fw_emul.c Wed Apr 04 21:17:34 2007 +0900
@@ -725,6 +725,8 @@ xen_pal_emulator(unsigned long index, u6
console_start_sync();
(*efi.reset_system)(EFI_RESET_SHUTDOWN,0,0,NULL);
} else {
+ printk (XENLOG_DEBUG dom%d/vcpu%d: going offline\n,
+ current-domain-domain_id, current-vcpu_id);
set_bit(_VPF_down, current-pause_flags);
vcpu_sleep_nosync(current);
status = PAL_STATUS_SUCCESS;
diff -r fc9e2f7920c9 xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c Fri Mar 30 17:18:42 2007 -0600
+++ b/xen/arch/ia64/xen/vcpu.c Wed Apr 04 21:17:34 2007 +0900
@@ -174,6 +174,9 @@ void vcpu_init_regs(struct vcpu *v)
INT_ENABLE_OFFSET(v);
VCPU(v, itv) = (1 16); /* timer vector masked */
}
+
+ /* to prevent a Reserved Field fault */
+ VCPU(v, pta) = 0x3c;
v-arch.domain_itm_last = -1L;
}
diff -r fc9e2f7920c9 xen/include/public/arch-ia64.h
--- a/xen/include/public/arch-ia64.hFri Mar 30 17:18:42 2007 -0600
+++ b/xen/include/public/arch-ia64.hWed Apr 04 21:17:34 2007 +0900
@@ -107,6 +107,11 @@ typedef unsigned long xen_ulong_t;
#define GFW_START(4*MEM_G -16*MEM_M)
#define GFW_SIZE (16*MEM_M)
+
+#define GFW_HOB_START(4*MEM_G-14*MEM_M)
+#define GFW_HOB_SIZE (1*MEM_M)
+
+#define SAL_RETURN_STUB_PADDR (GFW_HOB_START+GFW_HOB_SIZE-0x10)
struct pt_fpreg {
union {
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][Patch]AddtwoPALcallswhichfixSMPwindowsinstallation crashing bug
-Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2007年4月4日 0:58 To: Xu, Anthony Cc: xen-ia64-devel Subject: RE: [Xen-ia64-devel][Patch]AddtwoPALcallswhichfixSMPwindowsinstallation crashing bug In my testing, representing the processor as a DCST Montecito simply pushes the problem back so that you can't install on 4-way. A 5-way domain panics just like a 3-way domain w/o the patch. Are you seeing the same thing? This doesn't feel like the proper solution. Thanks, I can reproduce this issue, I'm looking at it Thanks, Anthony 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]Add two PAL calls which fix SMPwindowsinstallation crashing bug
On Wed, 2007-04-04 at 21:25 +0900, Kouya SHIMURA wrote: Hi Alex, Wing, I revised my patch(return to SAL). What do you think? This is still dirty since it uses the rest area of HOB. Is there any other good place for SAL_RETURN_STUB_PADDR? This seems to work too, but wouldn't it make more sense if the GFW did this on it's own? Writing code into the HOB does still seem like a bit of a kludge. Anthony, Tristan, any comments? +/* + * inject a emulation code for SAL Return state from OS_BOOT_RENDEZ + * + * 1: mov r28=0x28 // PAL_HALT + *break 0x11 // DOMN_PAL_REQUEST + *br.many.sptk.few 1 + */ +code = hob_buf + GFW_HOB_SIZE - 0x10; +code[0] = 0x2470e011; +code[1] = 0x40040010; Why PAL_HALT rather than SAL_XEN_SAL_RETURN? Tristan's GFW does this: alloc r2=ar.pfs,0,0,8,0 movl r32=0x0200 mov r33=r0 mov r34=r0 mov r35=r0 mov r36=r0 mov r37=r0 mov r38=r0 mov r39=r0 break 0x110001 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]Add two PAL calls which fix SMPwindowsinstallation crashing bug
Selon Alex Williamson [EMAIL PROTECTED]: On Wed, 2007-04-04 at 21:25 +0900, Kouya SHIMURA wrote: Hi Alex, Wing, I revised my patch(return to SAL). What do you think? This is still dirty since it uses the rest area of HOB. Is there any other good place for SAL_RETURN_STUB_PADDR? This seems to work too, but wouldn't it make more sense if the GFW did this on it's own? Writing code into the HOB does still seem like a bit of a kludge. Anthony, Tristan, any comments? IMHO the Intel GFW can do all this work, there is no needs to do it in the hypervisor. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch][RFC] Auto setup serial console on PRIMEQUEST
Hi,
I make a patch to use serial console without setting bootparameter on PQ.
I change the intel_tiger_console_setup(),
but should I add a function for PRIMEQUEST?
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
---
diff -r 56caf0e37e6a xen/arch/ia64/linux-xen/setup.c
--- a/xen/arch/ia64/linux-xen/setup.c Mon Mar 26 10:10:31 2007 -0600
+++ b/xen/arch/ia64/linux-xen/setup.c Thu Apr 05 12:01:40 2007 +0900
@@ -316,7 +316,7 @@ io_port_init (void)
#ifdef XEN
static int __init
-intel_tiger_console_setup(void)
+machine_console_setup(void)
{
extern struct ns16550_defaults ns16550_com1;
efi_system_table_t *systab;
@@ -352,9 +352,19 @@ intel_tiger_console_setup(void)
if (strncmp(hdr-signature, XSDT_SIG, sizeof(XSDT_SIG) - 1))
return -ENODEV;
-
/*
-* Only looking for Intel Tiger systems
+* looking for Fujitsu PRIMEQUEST systems
+*/
+ if (!strncmp(hdr-oem_id, FUJITSPQ, 8)
+ (!strncmp(hdr-oem_table_id, PQ, 2))){
+ ns16550_com1.baud = BAUD_AUTO;
+ ns16550_com1.io_base = 0x3f8;
+ ns16550_com1.irq = 48;
+ return 0;
+ }
+
+ /*
+* looking for Intel Tiger systems
* Tiger 2: SR870BH2
* Tiger 4: SR870BN4
*/
@@ -402,7 +412,7 @@ early_console_setup (char *cmdline)
#endif
#ifdef XEN
- if (!intel_tiger_console_setup())
+ if (!machine_console_setup())
earlycons++;
#endif
return (earlycons) ? 0 : -1;
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] [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. I change the intel_tiger_console_setup(), but should I add a function for PRIMEQUEST? Hi Akio, Looks good. I might change machine_console_setup() to acpi_oem_console_setup() (no need for a new patch), but I don't see a need for a separate function. So the PRIMEQUEST system don't implement an HCDP table either? 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][RFC] Auto setup serial console onPRIMEQUEST
Hi, Alex Thank you for your work. PRIMEQUEST probalbly don't have HCDP table because we see the following boot message. (There is not HCDP=%lx message.) EFI v1.10 by Fujitsu: SALsystab=0x7fded700 ACPI 2.0=0x7fc7c000 SMBIOS=0xf Best Regards, Akio Takebe 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. I change the intel_tiger_console_setup(), but should I add a function for PRIMEQUEST? Hi Akio, Looks good. I might change machine_console_setup() to acpi_oem_console_setup() (no need for a new patch), but I don't see a need for a separate function. So the PRIMEQUEST system don't implement an HCDP table either? 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]Add two PAL calls which fix SMPwindowsinstallation crashing bug
In theory, our GFW should do that. I ever tried to just inject GP fault which caused by writing PTA to zero to guest and hope windows or GFW can handle the fault. However, the result is the VHPT miss fault raise again and again. So I think there may be something lost in our GFW, I will investigate into it. BTW: I can boot windows server 2003 enterprise edition SP1 with more than 8 vcpus. And all vcpus are available in windows's task manager. Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 2007年4月5日 3:01 To: Alex Williamson Cc: Kouya SHIMURA; Zhang, Xing Z; xen-ia64-devel; Xu, Anthony; Tristan Gingold Subject: RE: [Xen-ia64-devel][Patch]Add two PAL calls which fix SMPwindowsinstallation crashing bug Selon Alex Williamson [EMAIL PROTECTED]: On Wed, 2007-04-04 at 21:25 +0900, Kouya SHIMURA wrote: Hi Alex, Wing, I revised my patch(return to SAL). What do you think? This is still dirty since it uses the rest area of HOB. Is there any other good place for SAL_RETURN_STUB_PADDR? This seems to work too, but wouldn't it make more sense if the GFW did this on it's own? Writing code into the HOB does still seem like a bit of a kludge. Anthony, Tristan, any comments? IMHO the Intel GFW can do all this work, there is no needs to do it in the hypervisor. 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 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]Add two PAL calls which fix SMPwindowsinstallation crashing bug
On Thu, Apr 05, 2007 at 01:33:24PM +0900, Kouya SHIMURA wrote: 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. [...] 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. I fully agree. This is just a work-around. The hypervisor shouldn't initialize a register to a forbidden value. 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. ___ 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
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
