RE: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps
Tristan: We are talking about pv_ops interface calling convention, not hypervisor API convention. It should not violate each other because we still have hypervisor wrapper which can do the convertion. One thing in my mind is that when we do pv_ops, we stand in hypervisor neutral position. Only when we implement xen hypervisor wrapper of pv_ops, we stand on Xen. But yes, since we use single source, dual compile to generate code in place. Actually those pv_cpu_asm_ops won't be used frequently, most of them are not used. So even we use this policy, it is very few place which may use a formal pv_ops for ASM code which imply the calling convention. All IVT/gate table/page doesn't have this issue. Thanks, eddie -Original Message- From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2008年3月11日 17:24 To: Dong, Eddie Cc: Alex Williamson; xen-ia64-devel Subject: Re: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps Hi, just a point about call convention: I don't think switching to PAL static convention is a good idea as it doesn't work well with xen hyperprivop because of banked registers. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel]PATCH:vmx_init_env must be called on every processor
vmx_init_env must be called on every processor Signed-off-by: Anthony Xu [EMAIL PROTECTED] vp_init_env.patch Description: vp_init_env.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] fix behavior with unimplemented physical address
A behavior with unimplemented physical address on HVM is unpredictable.
An unimplemented data fault or an unimplemented instruction trap
should be raised.
Signed-off-by: Kouya Shimura [EMAIL PROTECTED]
diff -r 716a637722e4 xen/arch/ia64/vmx/vmx_fault.c
--- a/xen/arch/ia64/vmx/vmx_fault.c Mon Mar 10 11:55:40 2008 -0600
+++ b/xen/arch/ia64/vmx/vmx_fault.c Thu Mar 13 13:54:14 2008 +0900
@@ -328,6 +328,11 @@ static int vmx_handle_lds(REGS* regs)
return IA64_FAULT;
}
+static inline int unimpl_phys_addr (u64 paddr)
+{
+return (pa_clear_uc(paddr) MAX_PHYS_ADDR_BITS) != 0;
+}
+
/* We came here because the H/W VHPT walker failed to find an entry */
IA64FAULT
vmx_hpw_miss(u64 vadr, u64 vec, REGS* regs)
@@ -351,20 +356,26 @@ vmx_hpw_miss(u64 vadr, u64 vec, REGS* re
else
panic_domain(regs, wrong vec:%lx\n, vec);
-/* Physical mode and region is 0 or 4. */
mmu_mode = VMX_MMU_MODE(v);
if ((mmu_mode == VMX_MMU_PHY_DT
- || (mmu_mode == VMX_MMU_PHY_D type == DSIDE_TLB))
- (REGION_NUMBER(vadr) 3) == 0) {
+ || (mmu_mode == VMX_MMU_PHY_D type == DSIDE_TLB))) {
if (type == DSIDE_TLB) {
u64 pte;
/* DTLB miss. */
if (misr.sp) /* Refer to SDM Vol2 Table 4-11,4-12 */
return vmx_handle_lds(regs);
+if (unlikely(unimpl_phys_addr(vadr))) {
+unimpl_daddr(v);
+return IA64_FAULT;
+}
pte = lookup_domain_mpa(v-domain, pa_clear_uc(vadr), NULL);
-/* Clear UC bit in vadr with the shifts. */
if (v-domain != dom0 (pte GPFN_IO_MASK)) {
emulate_io_inst(v, pa_clear_uc(vadr), 4, pte);
+return IA64_FAULT;
+}
+} else {
+if (unlikely(unimpl_phys_addr(vadr))) {
+unimpl_iaddr_trap(v, vadr);
return IA64_FAULT;
}
}
diff -r 716a637722e4 xen/arch/ia64/vmx/vmx_virt.c
--- a/xen/arch/ia64/vmx/vmx_virt.c Mon Mar 10 11:55:40 2008 -0600
+++ b/xen/arch/ia64/vmx/vmx_virt.c Thu Mar 13 13:42:58 2008 +0900
@@ -277,9 +277,6 @@ static IA64FAULT vmx_emul_ptc_l(VCPU *vc
}
#ifdef VMAL_NO_FAULT_CHECK
if (unimplemented_gva(vcpu,r3) ) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -338,9 +335,6 @@ static IA64FAULT vmx_emul_ptc_g(VCPU *vc
}
#ifdef VMAL_NO_FAULT_CHECK
if (unimplemented_gva(vcpu,r3) ) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -374,9 +368,6 @@ static IA64FAULT vmx_emul_ptc_ga(VCPU *v
}
#ifdef VMAL_NO_FAULT_CHECK
if (unimplemented_gva(vcpu,r3) ) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -411,9 +402,6 @@ static IA64FAULT ptr_fault_check(VCPU *v
return IA64_FAULT;
}
if (unimplemented_gva(vcpu,r3) ) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -635,9 +623,6 @@ static IA64FAULT vmx_emul_itr_d(VCPU *vc
return IA64_FAULT;
}
if (unimplemented_gva(vcpu, ifa)) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -703,9 +688,6 @@ static IA64FAULT vmx_emul_itr_i(VCPU *vc
return IA64_FAULT;
}
if (unimplemented_gva(vcpu, ifa)) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -764,9 +746,6 @@ static IA64FAULT itc_fault_check(VCPU *v
}
#ifdef VMAL_NO_FAULT_CHECK
if (unimplemented_gva(vcpu,ifa) ) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
diff -r 716a637722e4 xen/include/asm-ia64/vmx_vcpu.h
--- a/xen/include/asm-ia64/vmx_vcpu.h Mon Mar 10 11:55:40 2008 -0600
+++ b/xen/include/asm-ia64/vmx_vcpu.h Thu Mar 13 13:55:46 2008 +0900
@@ -582,6 +582,11 @@ static inline void
static inline void
unimpl_daddr (VCPU *vcpu)
{
+ ISR isr;
+
+ isr.val = set_isr_ei_ni(vcpu);
+ isr.code = IA64_UNIMPL_DADDR_FAULT;
+ vcpu_set_isr(vcpu, isr.val);
_general_exception(vcpu);
}
@@ -695,4 +700,21 @@ data_access_rights(VCPU *vcpu, u64 vadr)
set_ifa_itir_iha(vcpu, vadr, 1, 1, 0);
Re: [Xen-ia64-devel] Mini-OS registers and libgcc
On Wed, Feb 13, 2008 at 01:59:05PM +0100, Dietmar Hahn wrote: Hi Samuel, comments are within the text! Am Mittwoch, 13. Februar 2008 schrieb Samuel Thibault: Hello, Dietmar Hahn, le Wed 13 Feb 2008 11:53:59 +0100, a écrit : Am Dienstag, 12. Februar 2008 schrieb Samuel Thibault: Is there a reason for using -mfixed-range=f2-f5,f12-f15,f32-f127 when compiling Mini-OS? Is it really needed since it doesn't have a user-land? (though I guess some support would be needed in switch_context for instance) To handle this in a clean way the trap_frame has to be expanded and some fp registers have to stored/restored in trap handling. Ok. Would this be needed in order to be able to use libgcc.a? No, both things are independent from each other. Humm not sure: libgcc uses f12-f15. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] cleanup set_psr_l
Hi, This patch cleanup vcpu_set_psr_l(). Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe cleanup_set_psr_l.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: cleanup in vmx_ivt.S
Hi, this patch removes the commented lines in order to make the code clearer. Tristan. # HG changeset patch # User Tristan Gingold [EMAIL PROTECTED] # Date 1205382564 -3600 # Node ID ac30e3a6b9fccc9d0213dc0eed7c1545c4312b1f # Parent 7a00b54e1ce9b0ec3930f7d78d5a519cf588d680 Cleanup: remove useless commented lines. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r 7a00b54e1ce9 -r ac30e3a6b9fc xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.S Wed Mar 12 06:46:15 2008 +0100 +++ b/xen/arch/ia64/vmx/vmx_ivt.S Thu Mar 13 05:29:24 2008 +0100 @@ -524,38 +524,33 @@ ENTRY(vmx_break_fault) * to prevent leaking bits from kernel to user level. */ -// mov.m r16=IA64_KR(CURRENT) // M2 r16 - current task (12 cyc) -mov r14=r21 -bsw.1 // B (6 cyc) regs are saved, switch to bank 1 +mov r14=r21// save r21 before bsw.1 +bsw.1 // B (6 cyc) switch to bank 1 ;; -mov r29=cr.ipsr// M2 (12 cyc) +mov r29=cr.ipsr// M2 (12 cyc) mov r31=pr // I0 (2 cyc) mov r16=r14 mov r15=r2 -mov r17=cr.iim // M2 (2 cyc) +mov r17=cr.iim // M2 (2 cyc) mov.m r27=ar.rsc // M2 (12 cyc) -// mov r18=__IA64_BREAK_SYSCALL // A - -mov.m ar.rsc=0 // M2 + +mov.m ar.rsc=0 // M2 mov.m r21=ar.fpsr // M2 (12 cyc) mov r19=b6 // I0 (2 cyc) ;; -mov.m r23=ar.bspstore // M2 (12 cyc) +mov.m r23=ar.bspstore // M2 (12 cyc) mov.m r24=ar.rnat // M2 (5 cyc) mov.i r26=ar.pfs // I0 (2 cyc) -invala // M0|1 -nop.m 0// M +invala // M0|1 +nop.m 0// M mov r20=r1 // Asave r1 nop.m 0 -// movl r30=sys_call_table// X -movl r30=ia64_hypercall_table // X - -mov r28=cr.iip // M2 (2 cyc) -// cmp.eq p0,p7=r18,r17 // I0 is this a system call? -//(p7) br.cond.spnt non_syscall // B no - +movl r30=ia64_hypercall_table // X + +mov r28=cr.iip // M2 (2 cyc) // // From this point on, we are definitely on the syscall-path // and we can use (non-banked) scratch registers. @@ -563,37 +558,30 @@ ENTRY(vmx_break_fault) /// mov r1=r16 // Amove task-pointer to addl-addressable reg mov r2=r16 // Asetup r2 for ia64_syscall_setup -// add r9=TI_FLAGS+IA64_TASK_SIZE,r16 // Ar9 = current_thread_info()-flags - -// adds r16=IA64_TASK_THREAD_ON_USTACK_OFFSET,r16 -// adds r15=-1024,r15 // Asubtract 1024 from syscall number -// mov r3=NR_syscalls - 1 + mov r3=NR_hypercalls - 1 ;; -// ld1.bias r17=[r16] // M0|1 r17 = current-thread.on_ustack flag -// ld4 r9=[r9]// M0|1 r9 = current_thread_info()-flags -mov r9=r0 // force flags = 0 +mov r9=r0 // force flags = 0 extr.u r8=r29,41,2 // I0 extract ei field from cr.ipsr -shladd r30=r15,3,r30 // Ar30 = sys_call_table + 8*(syscall-1024) +shladd r30=r15,3,r30 // Ar30 = hcall_table + 8*syscall addl r22=IA64_RBS_OFFSET,r1// Acompute base of RBS -cmp.leu p6,p7=r15,r3 // Asyscall number in range? +cmp.leu p6,p7=r15,r3 // Asyscall number in range? ;; lfetch.fault.excl.nt1 [r22]// M0|1 prefetch RBS -(p6) ld8 r30=[r30] // M0|1 load address of syscall entry point -tnat.nz.or p7,p0=r15 // I0 is syscall nr a NaT? - -mov.m ar.bspstore=r22 // M2 switch to kernel RBS +(p6) ld8 r30=[r30] // M0|1 load address of syscall entry point +tnat.nz.or p7,p0=r15 // I0 is syscall nr a NaT? + +mov.m ar.bspstore=r22 // M2 switch to kernel RBS cmp.eq p8,p9=2,r8 // Aisr.ei==2? ;; (p8) mov r8=0 // Aclear ei to 0 -//(p7) movl r30=sys_ni_syscall// X -(p7) movl r30=do_ni_hypercall // X - -(p8) adds r28=16,r28 // Aswitch cr.iip to next bundle -(p9) adds r8=1,r8
[Xen-ia64-devel] Re: [PATCH][OpenGFW] Enable to handle xm trigger domain init
On Wed, Mar 12, 2008 at 03:37:24PM +0900, SUZUKI Kazuhiro wrote: Hi Tristan, When `xm trigger domain init' is called, the guest domain panics on current OpenGFW. The following patch enables to send INIT to guest and to call INIT handlers(monarch and slave). Thanks! We now have to improve INIT virtualization (eg testing psr.mc, ...) Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH][OpenGFW] Enable to handle xm trigger domain init
Hi Tristan,
When `xm trigger domain init' is called, the guest domain panics on
current OpenGFW.
The following patch enables to send INIT to guest and to call INIT
handlers(monarch and slave).
Thanks,
KAZ
Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED]
diff -r 9e4b5bb76049 edk2-sparse/EdkXenPkg/Dxe/XenSal/Sal.c
--- a/edk2-sparse/EdkXenPkg/Dxe/XenSal/Sal.cWed Feb 20 16:26:26 2008 +0900
+++ b/edk2-sparse/EdkXenPkg/Dxe/XenSal/Sal.cFri Mar 07 09:28:05 2008 +0900
@@ -3,10 +3,13 @@
#define BUILD_CMD(addr) ((0x8000 | (addr)) ~3)
#define REG_OFFSET(addr) (0x00FF (addr))
-struct {
+struct Fptr {
UINT64 Ip;
UINT64 Gp;
} SalRendezVector;
+
+struct Fptr *SalMonarchInitVector = (struct Fptr *)0x8000ff80;
+struct Fptr *SalSlaveInitVector = (struct Fptr *)0x8000ff90 ;
STATIC
EFI_SAL_STATUS
@@ -108,11 +111,26 @@ SalProc
return (SAL_RETURN_REGS) {EFI_SAL_INVALID_ARGUMENT, r9, r10, r11};
}
status = EFI_SAL_SUCCESS;
- } else if (FunctionId == EFI_SAL_SET_VECTORS
- Arg2 == EFI_SAL_SET_BOOT_RENDEZ_VECTOR) {
-SalRendezVector.Ip = Arg3;
-SalRendezVector.Gp = Arg4;
-status = EFI_SAL_SUCCESS;
+ } else if (FunctionId == EFI_SAL_SET_VECTORS) {
+switch (Arg2) {
+case EFI_SAL_SET_MCA_VECTOR:
+ return SalEmulator (FunctionId, Arg2, Arg3, Arg4, Arg5, Arg6, Arg7,
Arg8);
+case EFI_SAL_SET_INIT_VECTOR:
+ SalMonarchInitVector-Ip = Arg3;
+ SalMonarchInitVector-Gp = Arg4;
+ SalSlaveInitVector-Ip = Arg6;
+ SalSlaveInitVector-Gp = Arg7;
+
+ status = EFI_SAL_SUCCESS;
+ return SalEmulator (FunctionId, Arg2, Arg3, Arg4, Arg5, Arg6, Arg7,
Arg8);
+case EFI_SAL_SET_BOOT_RENDEZ_VECTOR:
+ SalRendezVector.Ip = Arg3;
+ SalRendezVector.Gp = Arg4;
+ status = EFI_SAL_SUCCESS;
+ break;
+default:
+ return (SAL_RETURN_REGS) {EFI_SAL_INVALID_ARGUMENT, r9, r10, r11};
+}
} else {
return SalEmulator (FunctionId, Arg2, Arg3, Arg4, Arg5, Arg6, Arg7, Arg8);
}
diff -r 9e4b5bb76049 edk2-sparse/EdkXenPkg/SecMain/Ipf/startup.s
--- a/edk2-sparse/EdkXenPkg/SecMain/Ipf/startup.s Wed Feb 20 16:26:26
2008 +0900
+++ b/edk2-sparse/EdkXenPkg/SecMain/Ipf/startup.s Wed Mar 12 14:31:06
2008 +0900
@@ -12,6 +12,26 @@
#define SCRATCH_REG5r28
#define SCRATCH_REG6r29
#define PR_REG r30
+
+#defineUC_BIT (163)
+#define IA64_IPI_DEFAULT_BASE_ADDR 0xfee0
+#define IA64_IPI_DM_INIT 0x5
+
+/*
+ * Calculates percpu minstate address like `min_state + cpu_id * 0x200'.
+ * cr.lid is defined as follows.
+ * cr.lid = (id 24) | (eid 16)
+ * id and eid is set in EdkXenPkg/Dxe/XenAcpi/build.c.
+ * id = cpu_id
+ * eid = 0
+ */
+#defineMINSTATE(reg,tmp) \
+ mov tmp=cr.lid;;\
+ extrtmp=tmp,24,8; \
+ movlreg=min_state;; \
+ ld8 reg=[reg]; \
+ dep.z tmp=tmp,9,8;; \
+ add reg=tmp,reg
#define VECTOR(offset) \
.org base + offset ; \
@@ -943,6 +963,346 @@ 1:break 0
.endp _start
+ .align 16
+ .globl _init
+ .proc _init
+_init:
+ MINSTATE(r2,r3);;
+ mov r17=r2 // min_state
+ add r20=16,r2
+ mov r19=ar.unat
+ ;;
+ st8.spill [r20]=r19,8 // @0
+ ;;
+ st8.spill [r20]=r1,8 // @8
+ ;;
+ st8.spill [r20]=r2,8 // @10
+ ;;
+ st8.spill [r20]=r3,8 // @18
+ ;;
+ st8.spill [r20]=r4,8 // @20
+ ;;
+ st8.spill [r20]=r5,8 // @28
+ ;;
+ st8.spill [r20]=r6,8 // @30
+ ;;
+ st8.spill [r20]=r7,8 // @38
+ ;;
+ st8.spill [r20]=r8,8 // @40
+ ;;
+ st8.spill [r20]=r9,8 // @48
+ ;;
+ st8.spill [r20]=r10,8 // @50
+ ;;
+ st8.spill [r20]=r11,8 // @58
+ ;;
+ st8.spill [r20]=r12,8 // @60
+ ;;
+ st8.spill [r20]=r13,8 // @68
+ ;;
+ st8.spill [r20]=r14,8 // @70
+ ;;
+ add r9=8,r20
+ st8.spill [r20]=r15 // @78
+ ;;
+bsw.0;;
+srlz.d
+
+ st8.spill [r9]=r16,8 // @80
+ ;;
+ st8.spill [r9]=r17,8 // @88
+ ;;
+ st8.spill [r9]=r18,8 // @90
+ ;;
+ st8.spill [r9]=r19,8 // @98
+ ;;
+ st8.spill [r9]=r20,8 // @a0
+ ;;
+ st8.spill [r9]=r21,8 // @a8
+ ;;
+ st8.spill [r9]=r22,8 // @b0
+ ;;
+ st8.spill [r9]=r23,8 // @b8
+ ;;
+ st8.spill [r9]=r24,8 // @c0
+ ;;
+ st8.spill
Re: [Xen-ia64-devel] Mini-OS registers and libgcc
Tristan Gingold, le Wed 12 Mar 2008 17:19:55 +0100, a écrit : On Wed, Feb 13, 2008 at 01:59:05PM +0100, Dietmar Hahn wrote: comments are within the text! Am Mittwoch, 13. Februar 2008 schrieb Samuel Thibault: Hello, Dietmar Hahn, le Wed 13 Feb 2008 11:53:59 +0100, a écrit : Am Dienstag, 12. Februar 2008 schrieb Samuel Thibault: Is there a reason for using -mfixed-range=f2-f5,f12-f15,f32-f127 when compiling Mini-OS? Is it really needed since it doesn't have a user-land? (though I guess some support would be needed in switch_context for instance) To handle this in a clean way the trap_frame has to be expanded and some fp registers have to stored/restored in trap handling. Ok. Would this be needed in order to be able to use libgcc.a? No, both things are independent from each other. Humm not sure: libgcc uses f12-f15. Ok, so with the red zone of x86_64, that's another reason for not using it :/ Samuel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] fix behavior with unimplemented physical address
On Thu, Mar 13, 2008 at 02:31:03PM +0900, Kouya Shimura wrote: Content-Description: message body text A behavior with unimplemented physical address on HVM is unpredictable. An unimplemented data fault or an unimplemented instruction trap should be raised. I think you shouldn't remove the region test. vpsr.rt may still be set in some modes. This is to be discussed (so it might be easier to split this patch in two pieces). Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] GFW release
Hi, I have just updated the GFW binary. Please test it. If it is OK, it will be used for the official GFW release. [ I made this patch before adding INIT support. Should I make a new release ?] Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] need advices for vcpu params
Hi, I have a general question for implementing an ia64 specific feature. The ia64 architecture has several parameters not fixed: number of itr, dtr and pk registers, size of virtual addresses, size of physical addresses, size of rid and pk... It would be nie to be able to specify these parameters when a domain is created (as this will open new doors). What is the best way to add these not-for-newbie parameters: - adding them one per one, eg: vcpu_nbr_itrs=8 ... - adding only one generic parameter such as: vcpu_params=nbr_itrs=9 nbr_dtrs=8 and parsing this string in the libxc domain builder. Thanks for ideas or opinions, Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Xen debugging on ia64? gdbserver-xen or other tools?
Hi everyone, I'm trying to debug an issue that looks to be related to the way the guest firmware sets up the various EFI tables. Has anyone gotten gdbserver-xen to work under IA64? When I try to compile it, I get the following compile error: gcc-o gdbserver-xen inferiors.o regcache.o remote-utils.o server.o signals.o target.o utils.o mem-break.o reg-ia64.o linux-low.o linux-ia64-low.o \ -L../../../../../libxc/ -lxenctrl server.o(.text+0x12d1): In function `ctrl_c_handler': ../../../gdb-6.2.1/gdb/gdbserver/server.c:346: undefined reference to `control_c_pressed_flag' server.o(.text+0x12e1):../../../gdb-6.2.1/gdb/gdbserver/server.c:346: undefined reference to `control_c_pressed_flag' collect2: ld returned 1 exit status It looks like maybe this code is x86-specific. How does one debug Xen related issues? What tools do you all use? Thanks for your replies. ---Kayvan ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] GFW release
Hi Tristan, [ I made this patch before adding INIT support. Should I make a new release ?] Please add INIT support to a binary release. I want you to release a new one. Thanks, KAZ From: Tristan Gingold [EMAIL PROTECTED] Subject: [Xen-ia64-devel] GFW release Date: Thu, 13 Mar 2008 13:46:27 +0100 Hi, I have just updated the GFW binary. Please test it. If it is OK, it will be used for the official GFW release. [ I made this patch before adding INIT support. Should I make a new release ?] Tristan. ___ 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] GFW release
I checked it at kvm side. It also works well. :) Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tristan Gingold Sent: 2008年3月13日 20:46 To: Xen-ia64-devel Subject: [Xen-ia64-devel] GFW release Hi, I have just updated the GFW binary. Please test it. If it is OK, it will be used for the official GFW release. [ I made this patch before adding INIT support. Should I make a new release ?] Tristan. ___ 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] fix behavior with unimplemented physical address
Hi Tristan, You are right. I forgot about register stack translation. Thank you for pointing out. I'll split the patch. umm, this seems to be quite troublesome. Thanks, Kouya Tristan Gingold writes: I think you shouldn't remove the region test. vpsr.rt may still be set in some modes. This is to be discussed (so it might be easier to split this patch in two pieces). ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] raise a fault with unimplemented physical address
An unimplemented data fault or an unimplemented instruction trap
should be raised with unimplemented physical address.
Also some cleanups.
Signed-off-by: Kouya Shimura [EMAIL PROTECTED]
diff -r 716a637722e4 xen/arch/ia64/vmx/vmx_fault.c
--- a/xen/arch/ia64/vmx/vmx_fault.c Mon Mar 10 11:55:40 2008 -0600
+++ b/xen/arch/ia64/vmx/vmx_fault.c Fri Mar 14 11:03:35 2008 +0900
@@ -328,6 +328,11 @@ static int vmx_handle_lds(REGS* regs)
return IA64_FAULT;
}
+static inline int unimpl_phys_addr (u64 paddr)
+{
+return (pa_clear_uc(paddr) MAX_PHYS_ADDR_BITS) != 0;
+}
+
/* We came here because the H/W VHPT walker failed to find an entry */
IA64FAULT
vmx_hpw_miss(u64 vadr, u64 vec, REGS* regs)
@@ -361,10 +366,18 @@ vmx_hpw_miss(u64 vadr, u64 vec, REGS* re
/* DTLB miss. */
if (misr.sp) /* Refer to SDM Vol2 Table 4-11,4-12 */
return vmx_handle_lds(regs);
+if (unlikely(unimpl_phys_addr(vadr))) {
+unimpl_daddr(v);
+return IA64_FAULT;
+}
pte = lookup_domain_mpa(v-domain, pa_clear_uc(vadr), NULL);
-/* Clear UC bit in vadr with the shifts. */
if (v-domain != dom0 (pte GPFN_IO_MASK)) {
emulate_io_inst(v, pa_clear_uc(vadr), 4, pte);
+return IA64_FAULT;
+}
+} else {
+if (unlikely(unimpl_phys_addr(vadr))) {
+unimpl_iaddr_trap(v, vadr);
return IA64_FAULT;
}
}
diff -r 716a637722e4 xen/arch/ia64/vmx/vmx_virt.c
--- a/xen/arch/ia64/vmx/vmx_virt.c Mon Mar 10 11:55:40 2008 -0600
+++ b/xen/arch/ia64/vmx/vmx_virt.c Fri Mar 14 11:02:24 2008 +0900
@@ -277,9 +277,6 @@ static IA64FAULT vmx_emul_ptc_l(VCPU *vc
}
#ifdef VMAL_NO_FAULT_CHECK
if (unimplemented_gva(vcpu,r3) ) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -338,9 +335,6 @@ static IA64FAULT vmx_emul_ptc_g(VCPU *vc
}
#ifdef VMAL_NO_FAULT_CHECK
if (unimplemented_gva(vcpu,r3) ) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -374,9 +368,6 @@ static IA64FAULT vmx_emul_ptc_ga(VCPU *v
}
#ifdef VMAL_NO_FAULT_CHECK
if (unimplemented_gva(vcpu,r3) ) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -411,9 +402,6 @@ static IA64FAULT ptr_fault_check(VCPU *v
return IA64_FAULT;
}
if (unimplemented_gva(vcpu,r3) ) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -635,9 +623,6 @@ static IA64FAULT vmx_emul_itr_d(VCPU *vc
return IA64_FAULT;
}
if (unimplemented_gva(vcpu, ifa)) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -703,9 +688,6 @@ static IA64FAULT vmx_emul_itr_i(VCPU *vc
return IA64_FAULT;
}
if (unimplemented_gva(vcpu, ifa)) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
@@ -764,9 +746,6 @@ static IA64FAULT itc_fault_check(VCPU *v
}
#ifdef VMAL_NO_FAULT_CHECK
if (unimplemented_gva(vcpu,ifa) ) {
-isr.val = set_isr_ei_ni(vcpu);
-isr.code = IA64_RESERVED_REG_FAULT;
-vcpu_set_isr(vcpu, isr.val);
unimpl_daddr(vcpu);
return IA64_FAULT;
}
diff -r 716a637722e4 xen/include/asm-ia64/vmx_vcpu.h
--- a/xen/include/asm-ia64/vmx_vcpu.h Mon Mar 10 11:55:40 2008 -0600
+++ b/xen/include/asm-ia64/vmx_vcpu.h Fri Mar 14 11:02:24 2008 +0900
@@ -582,6 +582,11 @@ static inline void
static inline void
unimpl_daddr (VCPU *vcpu)
{
+ ISR isr;
+
+ isr.val = set_isr_ei_ni(vcpu);
+ isr.code = IA64_UNIMPL_DADDR_FAULT;
+ vcpu_set_isr(vcpu, isr.val);
_general_exception(vcpu);
}
@@ -695,4 +700,21 @@ data_access_rights(VCPU *vcpu, u64 vadr)
set_ifa_itir_iha(vcpu, vadr, 1, 1, 0);
inject_guest_interruption(vcpu, IA64_DATA_ACCESS_RIGHTS_VECTOR);
}
+
+/*
+ * Unimplement Instruction Address Trap
+ * @ Lower-Privilege Transfer Trap Vector
+ * Refer to SDM Vol2 Table 5-6 8-1
+ */
+static inline void
+unimpl_iaddr_trap (VCPU *vcpu, u64 vadr)
+{
+ ISR isr;
+
+ isr.val = set_isr_ei_ni(vcpu);
+ isr.code = IA64_UNIMPL_IADDR_TRAP;
+ vcpu_set_isr(vcpu, isr.val);
+
[Xen-ia64-devel] Re: [patch] ia64: kexec: add __va_efi
On Fri, 2008-03-14 at 10:51 +0900, Simon Horman wrote: On an HP rx2600 this eliminates the problem where the SAL rendezvous address can't be registered and subsequently the boot fails. I suspect it solves similar problems that have been seen on other HP machines too. Actually, its rather amazing that the HP rx2620 and Tiger2 that I have been using work without this fix. Wow, that is rather surprising. Congratulations on tracking this down. I'll try to verify if this also solves the problem on superdome tomorrow. 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] GFW release
On Fri, Mar 14, 2008 at 09:53:49AM +0800, Zhang, Xiantao wrote: I checked it at kvm side. It also works well. :) Good news! Thank you for the report. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
