[Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11265
Xen/IA64 Healthiness Report Nightly testing still meet several issues. I reported a bug about xm list fail, after try to create 4 XenU guest at the same time. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=747 Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core) PAL version: 8.15 Service OS: RHEL4u3 IA64 VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 11265:3e54734e55f3 Xen Schedule: credit VTI Guest Firmware MD5: b6277539d86d785d8859ea2f99cf6013 Summary Test Report: - Total cases: 15 Passed:10 Failed: 5 Detailed test cases info: - One_VTI_without_vif__fail__(Note1) One_VTI pass One_XenU pass Two_VTI_Coexist __fail__ One_VTI_and_One_XenU pass Two_XenU_Coexist pass One_VTI_4096M pass VTI_Network __fail__(Note2) XenU_Network pass One_SMP_XenU pass One_SMP_VTI __fail__ (Note1) UP_VTI_LTP pass VTI_Kernel_Build pass Four_VTI_Coexist __fail__ (Note3) VTI_Windows pass Notes: - 1. kenel panic:nightly test met the kernel panic in 2 cases ( SMP_VTI and VTI_Witnout_Vif). 2. Network failed in this Cset, in case VTI_network creating passed but ping failed. 3. Multi_VTI_Coexist failed to be created, both in 2_VTI and 4_VTI. But 2_VTI coexist testing can pass manual testing. 4 VTI domains coexisting testing can pass, if using SMP xen0. The last stable changeset: - 10706:2db50529223e Best Regards, Yongkang (Kangkang) 永康 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] RFC: xencomm in common
Le Jeudi 24 Août 2006 03:44, Isaku Yamahata a écrit : Hi Tristan. Since I looked the patch very roughly, I might be wrong and parania though. xencomm_copy_from_guest(), xencomm_copy_to_guest() converts address, then acessses a page. The Xen/IA64 P2M table is lockless so that the page can be freed by another cpu and used for other purpose at the same time. (Actually such a guest behaviour doesn't make sense, but possible.) get_page()/put_page() are necessary to prevent such a situation. Actually Xen/IA64's vcpu_get_domain_bundle() and efi_translate_domain_addr() do it. Ok, I have to add get_page/put_page. Thank you for the comment. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
PATCH: cleanup - was Re: [Xen-ia64-devel] xen-ia64-unstable.hg status
Le Jeudi 24 Août 2006 00:44, Alex Williamson a écrit :
I merged us up with xen-unstable.hg. For the most part things still
work well, but there seem to be a few regressions (networking on VTi
domains is broken again and rebooting domains is less reliable). I'd
like to request a pull within the next day or so, therefore please take
a moment to test as this may be our last pull before 3.0.3. I'd like to
include all of the currently outstanding patches, especially the
pal_halt_light emulation patch, so let's try to get that one figured out
so that everyone is happy with it. Thanks,
Hi,
very small patch to avoid compile-time warning.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID e85eb1425baaa314ef10cb600c376bba3c9a8298
# Parent 3e54734e55f39419678afd1ce1a9a96669fa69ef
Avoid compile-time warnings.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 3e54734e55f3 -r e85eb1425baa xen/include/asm-ia64/grant_table.h
--- a/xen/include/asm-ia64/grant_table.h Wed Aug 23 13:26:46 2006 -0600
+++ b/xen/include/asm-ia64/grant_table.h Thu Aug 24 08:07:26 2006 +0200
@@ -35,7 +35,7 @@ void guest_physmap_add_page(struct domai
gnttab_shared_maddr((d), (t), (i))); \
(IA64_GRANT_TABLE_PADDR PAGE_SHIFT) + (i);})
-#define gnttab_mark_dirty(d, f) ((void)0)
+#define gnttab_mark_dirty(d, f) ((void)f)
static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
{
diff -r 3e54734e55f3 -r e85eb1425baa xen/include/asm-ia64/vmx.h
--- a/xen/include/asm-ia64/vmx.h Wed Aug 23 13:26:46 2006 -0600
+++ b/xen/include/asm-ia64/vmx.h Thu Aug 24 08:07:26 2006 +0200
@@ -55,6 +55,7 @@ extern void vmx_relinquish_guest_resourc
extern void vmx_relinquish_guest_resources(struct domain *d);
extern void vmx_relinquish_vcpu_resources(struct vcpu *v);
extern void vmx_die_if_kernel(char *str, struct pt_regs *regs, long err);
+extern void vmx_send_assist_req(struct vcpu *v);
static inline vcpu_iodata_t *get_vio(struct domain *d, unsigned long cpu)
{
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 2/2] vdso fix
2 / 2 # HG changeset patch # User [EMAIL PROTECTED] # Date 1156328955 -32400 # Node ID 56645e1eb4c5d4e3fdd082f6610d2d5a737a795f # Parent 663a9be17ecda33b0f7a17882bd35789544a8f02 fix vDSO. __kernel_syscall_via_epc masks interrupt assuming page fault on the vDSO page can't occur during executing. However Xen might preempt vcpu when interrupt is disabled so that page fault might occur with interrupt masked unlike baremetal case. Such page fault results in acquiring semaphore with interrupt disabled. see ia64_do_page_fault(). It means that we can't disable interrupt in vDSO page on xen environment. So we jumps kernel text area which is pinned by ITR before disabling interrupt to avoid such page fault. PATCHNAME: fix_vdso Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff -r 663a9be17ecd -r 56645e1eb4c5 linux-2.6-xen-sparse/arch/ia64/kernel/gate.S --- a/linux-2.6-xen-sparse/arch/ia64/kernel/gate.S Wed Aug 23 17:44:28 2006 +0900 +++ b/linux-2.6-xen-sparse/arch/ia64/kernel/gate.S Wed Aug 23 19:29:15 2006 +0900 @@ -14,7 +14,7 @@ #include asm/sigcontext.h #include asm/system.h #include asm/unistd.h -#ifdef CONFIG_XEN_IA64_VDSO_PARAVIRT +#ifdef CONFIG_XEN # include asm/privop.h #endif @@ -36,7 +36,7 @@ [1:](pr)brl.cond.sptk 0; \ .xdata4 .data.patch.brl_fsys_bubble_down, 1b-. -#ifdef CONFIG_XEN_IA64_VDSO_PARAVIRT +#ifdef CONFIG_XEN // The page in which hyperprivop lives must be pinned by ITR. // However vDSO area isn't pinned. So issuing hyperprivop // from vDSO page causes trouble that Kevin pointed out. @@ -47,6 +47,17 @@ // which is pinned, and then issue hyperprivop and return back // to vDSO page. // This is Dan Magenheimer's idea. + // + // notes on page fault. + // __kernel_syscall_via_epc masks interrupt assuming page fault on the vDSO page + // can't occur during executing. + // However Xen might preempt vcpu when interrupt is disabled so that + // page fault might occur with interrupt masked unlike baremetal case. + // Such page fault results in acquiring semaphore with interrupt disabled. + // see ia64_do_page_fault(). + // It mean that we can't disable interrupt in vDSO page on xen environment. + // So we jumps kernel text area which is pinned by ITR before disabling interrupt + // to avoid such page fault. // Currently is_running_on_xen() is defined as running_on_xen. // If is_running_on_xen() is a real function, we must update @@ -57,29 +68,11 @@ [1:] movl reg=0; \ .xdata4 .data.patch.running_on_xen, 1b-. - .section .data.patch.brl_xen_rsm_be_i, a + .section .data.patch.brl___xen_kernel_syscall_via_epc, a .previous -#define BRL_COND_XEN_RSM_BE_I(pr) \ -[1:](pr)brl.cond.sptk 0; \ - .xdata4 .data.patch.brl_xen_rsm_be_i, 1b-. - - .section .data.patch.brl_xen_get_psr, a - .previous -#define BRL_COND_XEN_GET_PSR(pr) \ -[1:](pr)brl.cond.sptk 0; \ - .xdata4 .data.patch.brl_xen_get_psr, 1b-. - - .section .data.patch.brl_xen_ssm_i_0, a - .previous -#define BRL_COND_XEN_SSM_I_0(pr) \ -[1:](pr)brl.cond.sptk 0; \ - .xdata4 .data.patch.brl_xen_ssm_i_0, 1b-. - - .section .data.patch.brl_xen_ssm_i_1, a - .previous -#define BRL_COND_XEN_SSM_I_1(pr) \ -[1:](pr)brl.cond.sptk 0; \ - .xdata4 .data.patch.brl_xen_ssm_i_1, 1b-. +#define BRL_COND___XEN_KERNEL_SYSCALL_VIA_EPC(pr) \ +[1:](pr)brl.cond.sptk 0; \ + .xdata4 .data.patch.brl___xen_kernel_syscall_via_epc, 1b-. #endif GLOBAL_ENTRY(__kernel_syscall_via_break) @@ -126,9 +119,9 @@ GLOBAL_ENTRY(__kernel_syscall_via_epc) epc // Bcauses split-issue } ;; -#ifdef CONFIG_XEN_IA64_VDSO_PARAVIRT +#ifdef CONFIG_XEN // r20 = 1 - // r22 = vcpu-evtchn_mask + // r22 = vcpu-intrrupt_mask_addr // r23 = vpsr.ic // r24 = vcpu-pending_interruption // r25 = tmp @@ -137,28 +130,24 @@ GLOBAL_ENTRY(__kernel_syscall_via_epc) // r31 = tmp // p11 = tmp // p12 = running_on_xen - // p13 = !running_on_xen // p14 = tmp // p15 = tmp #define isXen p12 -#define isRaw p13 LOAD_RUNNING_ON_XEN(r28) +#ifdef CONFIG_XEN_IA64_VDSO_PARAVIRT movl r22=XSI_PSR_I_ADDR movl r23=XSI_PSR_IC movl r24=XSI_PSR_I_ADDR+(XSI_PEND_OFS-XSI_PSR_I_ADDR_OFS) mov r20=1 +#endif ;; ld4 r30=[r28] ;; - cmp.ne isXen,isRaw=r0,r30 - ;; -(isRaw)rsm psr.be | psr.i - BRL_COND_XEN_RSM_BE_I(isXen) -
[Xen-ia64-devel] [PATCH 0/2] vdso fix
__kernel_syscall_via_epc masks interrupt assuming page fault on the vDSO page can't occur during executing. However Xen might preempt vcpu when interrupt is disabled so that page fault might occur with interrupt masked unlike baremetal case. Such page fault results in acquiring semaphore with interrupt disabled. see ia64_do_page_fault(). It means that we can't disable interrupt in vDSO page on xen environment. So we jumps kernel text area which is pinned by ITR before disabling interrupt to avoid such page fault. thanks. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 1/2] import gate.s as xengate.s
1 / 2
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1156322668 -32400
# Node ID 663a9be17ecda33b0f7a17882bd35789544a8f02
# Parent 3e54734e55f39419678afd1ce1a9a96669fa69ef
copyed ia64 gate.S as xengate.S
PATCHNAME: import_gate_s_as_xengate_s
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 3e54734e55f3 -r 663a9be17ecd
linux-2.6-xen-sparse/arch/ia64/xen/xengate.S
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/xengate.S Wed Aug 23 17:44:28
2006 +0900
@@ -0,0 +1,376 @@
+/*
+ * This file contains the code that gets mapped at the upper end of each
task's text
+ * region. For now, it contains the signal trampoline code only.
+ *
+ * Copyright (C) 1999-2003 Hewlett-Packard Co
+ * David Mosberger-Tang [EMAIL PROTECTED]
+ */
+
+#include linux/config.h
+
+#include asm/asmmacro.h
+#include asm/errno.h
+#include asm/asm-offsets.h
+#include asm/sigcontext.h
+#include asm/system.h
+#include asm/unistd.h
+
+/*
+ * We can't easily refer to symbols inside the kernel. To avoid full runtime
relocation,
+ * complications with the linker (which likes to create PLT stubs for branches
+ * to targets outside the shared object) and to avoid multi-phase kernel
builds, we
+ * simply create minimalistic patch lists in special ELF sections.
+ */
+ .section .data.patch.fsyscall_table, a
+ .previous
+#define LOAD_FSYSCALL_TABLE(reg) \
+[1:] movl reg=0; \
+ .xdata4 .data.patch.fsyscall_table, 1b-.
+
+ .section .data.patch.brl_fsys_bubble_down, a
+ .previous
+#define BRL_COND_FSYS_BUBBLE_DOWN(pr) \
+[1:](pr)brl.cond.sptk 0; \
+ .xdata4 .data.patch.brl_fsys_bubble_down, 1b-.
+
+GLOBAL_ENTRY(__kernel_syscall_via_break)
+ .prologue
+ .altrp b6
+ .body
+ /*
+* Note: for (fast) syscall restart to work, the break instruction must
be
+* the first one in the bundle addressed by syscall_via_break.
+*/
+{ .mib
+ break 0x10
+ nop.i 0
+ br.ret.sptk.many b6
+}
+END(__kernel_syscall_via_break)
+
+/*
+ * On entry:
+ * r11 = saved ar.pfs
+ * r15 = system call #
+ * b0 = saved return address
+ * b6 = return address
+ * On exit:
+ * r11 = saved ar.pfs
+ * r15 = system call #
+ * b0 = saved return address
+ * all other scratch registers: undefined
+ * all preserved registers: same as on entry
+ */
+
+GLOBAL_ENTRY(__kernel_syscall_via_epc)
+ .prologue
+ .altrp b6
+ .body
+{
+ /*
+* Note: the kernel cannot assume that the first two instructions in
this
+* bundle get executed. The remaining code must be safe even if
+* they do not get executed.
+*/
+ adds r17=-1024,r15 // A
+ mov r10=0 // Adefault to successful
syscall execution
+ epc // Bcauses split-issue
+}
+ ;;
+ rsm psr.be | psr.i // M2 (5 cyc to srlz.d)
+ LOAD_FSYSCALL_TABLE(r14)// X
+ ;;
+ mov r16=IA64_KR(CURRENT)// M2 (12 cyc)
+ shladd r18=r17,3,r14// A
+ mov r19=NR_syscalls-1 // A
+ ;;
+ lfetch [r18]// M0|1
+ mov r29=psr // M2 (12 cyc)
+ // If r17 is a NaT, p6 will be zero
+ cmp.geu p6,p7=r19,r17 // A(sysnr 0 sysnr
1024+NR_syscalls)?
+ ;;
+ mov r21=ar.fpsr // M2 (12 cyc)
+ tnat.nz p10,p9=r15 // I0
+ mov.i r26=ar.pfs// I0 (would stall anyhow due
to srlz.d...)
+ ;;
+ srlz.d // M0 (forces split-issue)
ensure PSR.BE==0
+(p6) ld8 r18=[r18] // M0|1
+ nop.i 0
+ ;;
+ nop.m 0
+(p6) tbit.z.unc p8,p0=r18,0 // I0 (dual-issues with mov
b7=r18!)
+ nop.i 0
+ ;;
+(p8) ssm psr.i
+(p6) mov b7=r18 // I0
+(p8) br.dptk.many b7 // B
+
+ mov r27=ar.rsc // M2 (12 cyc)
+/*
+ * brl.cond doesn't work as intended because the linker would convert this
branch
+ * into a branch to a PLT. Perhaps there will be a way to avoid this with some
+ * future version of the linker. In the meantime, we just use an indirect
branch
+ * instead.
+ */
+#ifdef CONFIG_ITANIUM
+(p6) add r14=-8,r14 // r14 - addr of
fsys_bubble_down entry
+ ;;
+(p6) ld8 r14=[r14] // r14 - fsys_bubble_down
+ ;;
+(p6) mov b7=r14
+(p6) br.sptk.many b7
+#else
+ BRL_COND_FSYS_BUBBLE_DOWN(p6)
+#endif
+ ssm psr.i
+ mov r10=-1
+(p10)
[Xen-ia64-devel] [FYI] FC6 kernel and latest xen
Hi, I tried to boot dom0/domU with netfront/netback module. I can boot up dom0/domU with Kouya's patch. My environment is; - dom0/domU kernel http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora cset #35247 - xen tools http://xenbits.xensource.com/ext/xen-ia64-unstable.hg cset #11048 - Machine Tiger4 But I have many error message. [EMAIL PROTECTED] ~]# kernel unaligned access to 0xe000187a4e1e, ip= 0xa001004fad50 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a4e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xe0001662921e, ip=0xa001004fad50 kernel unaligned access to 0xe0001662921e, ip=0xa001004fae21 kernel unaligned access to 0xe0001662921e, ip=0xa001004faed0 kernel unaligned access to 0xe0001662922e, ip=0xa001004fb130 kernel unaligned access to 0xe0001662921e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a5e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xedf1a61e, ip=0xa001004fad50 kernel unaligned access to 0xedf1a61e, ip=0xa001004fae21 kernel unaligned access to 0xedf1a61e, ip=0xa001004faed0 kernel unaligned access to 0xedf1a62e, ip=0xa001004fb130 kernel unaligned access to 0xedf1a61e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a501e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a501e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a501e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a502e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a501e, ip=0xa001004fb2e0 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 0/2] vdso fix
This explanation is wrong. Please ignore those patches. Sorry for confution. On Thu, Aug 24, 2006 at 06:42:16PM +0900, Isaku Yamahata wrote: __kernel_syscall_via_epc masks interrupt assuming page fault on the vDSO page can't occur during executing. However Xen might preempt vcpu when interrupt is disabled so that page fault might occur with interrupt masked unlike baremetal case. Such page fault results in acquiring semaphore with interrupt disabled. see ia64_do_page_fault(). It means that we can't disable interrupt in vDSO page on xen environment. So we jumps kernel text area which is pinned by ITR before disabling interrupt to avoid such page fault. thanks. ___ 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] [FYI] FC6 kernel and latest xen
Le Jeudi 24 Août 2006 13:00, Akio Takebe a écrit : Hi, I tried to boot dom0/domU with netfront/netback module. I can boot up dom0/domU with Kouya's patch. My environment is; - dom0/domU kernel http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora cset #35247 - xen tools http://xenbits.xensource.com/ext/xen-ia64-unstable.hg cset #11048 - Machine Tiger4 But I have many error message. [EMAIL PROTECTED] ~]# kernel unaligned access to 0xe000187a4e1e, ip= 0xa001004fad50 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a4e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xe0001662921e, ip=0xa001004fad50 kernel unaligned access to 0xe0001662921e, ip=0xa001004fae21 kernel unaligned access to 0xe0001662921e, ip=0xa001004faed0 kernel unaligned access to 0xe0001662922e, ip=0xa001004fb130 kernel unaligned access to 0xe0001662921e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a5e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xedf1a61e, ip=0xa001004fad50 kernel unaligned access to 0xedf1a61e, ip=0xa001004fae21 kernel unaligned access to 0xedf1a61e, ip=0xa001004faed0 kernel unaligned access to 0xedf1a62e, ip=0xa001004fb130 kernel unaligned access to 0xedf1a61e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a501e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a501e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a501e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a502e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a501e, ip=0xa001004fb2e0 I suppose these are the usual bridge unaligned access log. You should check with IP. Is anyone working on this ? Tristan. ___ 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 driver for IPF
Le Jeudi 24 Août 2006 15:14, DOI Tsunehisa a écrit :
Hi all,
Hi,
I will post patches of PV-on-HVM for IPF.
We wrote the patch under this consideration:
* Expand hvm_op hypercall
+ Introduce HVMOP_setup_shared_info_page
- A page allocated on HVM-guest OS is swapped original shared_info
page with this hypercall.
- In x86 code, original shared_info page is used after pv-on-hvm
setup with remapping feature in arch depend HYPERVISOR_memory_op.
But, we can't implement same feature for IPF, thus we select to
implement with this method.
Can you explain why you can't reuse the HYPERVISOR_memory_op hcall ?
It isn't clear for me.
About the patch:
+static int
+vmx_gnttab_setup_table(unsigned long frame_pa, unsigned long nr_frames)
+{
+struct domain *d = current-domain;
+int rc = 0, i;
+unsigned long o_grant_shared, pgaddr;
+
+if (nr_frames != NR_GRANT_FRAMES) {
+return -1;
You'd better to return -EINVAL.
+}
+o_grant_shared = (unsigned long)d-grant_table-shared;
+d-grant_table-shared = (struct grant_entry *)domain_mpa_to_imva(d,
frame_pa);
+
+/* Copy existing grant table shared into new page */
+if (o_grant_shared) {
+memcpy((void*)d-grant_table-shared,
+(void*)o_grant_shared, PAGE_SIZE * nr_frames);
You should check the result of domain_mpa_to_imva, as it could fail.
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+}
+else {
+put_page(virt_to_page(pgaddr));
+}
May create a function to be called by gnttab_setup_table and
setup_shared_info_page.
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] xen-ia64-unstable.hg status
Alex, VTi network issue has be root caused to GFW conflict with latest QEMU addsing a fake PCI device (xen_platform) for VBD/VNIF which is using IRQ 10 same as NIC. A new GFW will be sent out separately. We have a patch for VTi Reboot issue but are seeing kernel panic, so we are continue to debug the new patch Thanks, -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:xen-ia64-devel- [EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: Wednesday, August 23, 2006 3:44 PM To: xen-ia64-devel Subject: [Xen-ia64-devel] xen-ia64-unstable.hg status I merged us up with xen-unstable.hg. For the most part things still work well, but there seem to be a few regressions (networking on VTi domains is broken again and rebooting domains is less reliable). I'd like to request a pull within the next day or so, therefore please take a moment to test as this may be our last pull before 3.0.3. I'd like to include all of the currently outstanding patches, especially the pal_halt_light emulation patch, so let's try to get that one figured out so that everyone is happy with it. 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 mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [XenPPC] PATCH: xencomm - kernel side
Le Mercredi 23 Août 2006 18:39, Hollis Blanchard a écrit :
On Wed, 2006-08-23 at 14:31 +0200, Tristan Gingold wrote:
taking into account Hollis comments I now submit this patch.
IA64 specific stuff will be posted to xen-ia64-unstable after merge.
NAK pending outcome of other comments.
Also, please let me add my own Signed-off-by line -- that way we'll know
that I agree the patch is in fact final (which I don't right now).
There is at least a /* XXX could we call this from irq context? */
comment that needs removal. I didn't check the rest of the patch to see
if you'd followed all my other suggestions.
I think the comment could be removed as this is never call during irq.
Here are the full patches (common and ia64). Only the common patches (mainly
11059) was formally submitted.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 80137e1a97cf27e026e6eb6a51a5757e160e979a
# Parent f32793cae274028d939dba4909be280c9df712a5
linux-ia64
diff -r f32793cae274 -r 80137e1a97cf linux-2.6-xen-sparse/arch/ia64/Kconfig
--- a/linux-2.6-xen-sparse/arch/ia64/Kconfig Wed Aug 23 11:12:25 2006 +0200
+++ b/linux-2.6-xen-sparse/arch/ia64/Kconfig Wed Aug 23 11:17:06 2006 +0200
@@ -530,6 +530,9 @@ config XEN_REBOOT
config XEN_SMPBOOT
default n
+
+config XEN_XENCOMM
+ default y
endif
source drivers/xen/Kconfig
diff -r f32793cae274 -r 80137e1a97cf linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Wed Aug 23 11:12:25 2006 +0200
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Wed Aug 23 11:17:06 2006 +0200
@@ -76,6 +76,8 @@ EXPORT_SYMBOL(__per_cpu_offset);
#endif
#ifdef CONFIG_XEN
+unsigned long kernel_start_pa;
+
static int
xen_panic_event(struct notifier_block *this, unsigned long event, void *ptr)
{
@@ -433,6 +435,7 @@ setup_arch (char **cmdline_p)
#ifdef CONFIG_XEN
if (is_running_on_xen()) {
+ kernel_start_pa = KERNEL_START - ia64_tpa (KERNEL_START);
setup_xen_features();
/* Register a call for panic conditions. */
notifier_chain_register(panic_notifier_list, xen_panic_block);
diff -r f32793cae274 -r 80137e1a97cf linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Wed Aug 23 11:12:25 2006 +0200
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Wed Aug 23 11:17:06 2006 +0200
@@ -70,7 +70,7 @@ ia64_xenmem_reservation_op(unsigned long
reservation.nr_extents = nr_extents;
dummy = frame_list[0];// re-install tlb entry before hypercall
- tmp_ret = HYPERVISOR_memory_op(op, reservation);
+ tmp_ret = xencomm_hypercall_memory_op(op, reservation);
if (tmp_ret 0) {
if (ret == 0) {
ret = tmp_ret;
@@ -371,8 +371,6 @@ int
int
HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count)
{
- __u64 va1, va2, pa1, pa2;
-
if (cmd == GNTTABOP_map_grant_ref) {
unsigned int i;
for (i = 0; i count; i++) {
@@ -380,29 +378,7 @@ HYPERVISOR_grant_table_op(unsigned int c
(struct gnttab_map_grant_ref*)uop + i);
}
}
- va1 = (__u64)uop PAGE_MASK;
- pa1 = pa2 = 0;
- if ((REGION_NUMBER(va1) == 5)
- ((va1 - KERNEL_START) = KERNEL_TR_PAGE_SIZE)) {
- pa1 = ia64_tpa(va1);
- if (cmd = GNTTABOP_transfer) {
- static uint32_t uop_size[GNTTABOP_transfer + 1] = {
-sizeof(struct gnttab_map_grant_ref),
-sizeof(struct gnttab_unmap_grant_ref),
-sizeof(struct gnttab_setup_table),
-sizeof(struct gnttab_dump_table),
-sizeof(struct gnttab_transfer),
- };
- va2 = (__u64)uop + (uop_size[cmd] * count) - 1;
- va2 = PAGE_MASK;
- if (va1 != va2) {
-/* maximum size of uop is 2pages */
-BUG_ON(va2 va1 + PAGE_SIZE);
-pa2 = ia64_tpa(va2);
- }
- }
- }
- return HYPERVISOR_grant_table_op(cmd, uop, count, pa1, pa2);
+ return xencomm_hypercall_grant_table_op(cmd, uop, count);
}
EXPORT_SYMBOL(HYPERVISOR_grant_table_op);
diff -r f32793cae274 -r 80137e1a97cf linux-2.6-xen-sparse/include/asm-ia64/hypercall.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Wed Aug 23 11:12:25 2006 +0200
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Wed Aug 23 11:17:06 2006 +0200
@@ -33,11 +33,12 @@
#ifndef __HYPERCALL_H__
#define __HYPERCALL_H__
-#include linux/string.h /* memcpy() */
-
#ifndef __HYPERVISOR_H__
# error please don't include this file directly
#endif
+
+#include xen/xencomm_hcall.h
+struct xencomm_handle;
/*
* Assembler stubs for hyper-calls.
@@ -157,16 +158,10 @@
(type)__res;\
})
-static inline int
-HYPERVISOR_sched_op_compat(
-int cmd, unsigned long arg)
-{
- return _hypercall2(int, sched_op_compat, cmd, arg);
-}
-
-static inline int
-HYPERVISOR_sched_op(
- int cmd, void *arg)
+
+static inline int
+xencomm_arch_hypercall_sched_op(
+ int cmd, struct xencomm_handle *arg)
{
return _hypercall2(int, sched_op, cmd, arg);
}
@@ -181,25 +176,22 @@ HYPERVISOR_set_timer_op(
}
static inline int
-HYPERVISOR_dom0_op(
-dom0_op_t
Re: [Xen-ia64-devel][PATCH]VTLB optimization: Reuse invalid entry
On Wed, 2006-08-23 at 22:56 +0800, Xu, Anthony wrote: When inserting entry to vtlb or vhpt, reuse invalid entry. Applied. -- 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] Re: PATCH: cleanup (asm constraints)
On Wed, 2006-08-23 at 17:54 +0200, Tristan Gingold wrote: Hi, After changing asm constraints, I removed _hypercall_imm*. Checked by objdump -dr Applied. -- 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 Summit ia64 topics
Hi Everyone, Xen Summit is just around the corner. Hopefully I'll see many of you there. I'd like to poll for topics people would like to discuss during the ia64 session. I expect that we'll have a rather informal session talking about the amazing amount of progress we've made since the last summit, and what we'd like to do next. Tristan sent out a list back in July with some roadmap ideas and we've already completed a number of things on the list. I believe the remaining ones are: * Profiling * Any page size support * Performance and stabilization I've also received some possible topics from Fred that include: * Planning for the upcoming stub-domain (mini-os) * Stability (distribution support) * Scalability * Performance * Making better use of TRs I'd really like to get all the x86/Xen debugging functionality ported over too. Adding NUMA support would be very relevant for many IPF systems. Tristan has already mentioned on list about improving bootloader interactions/parameters. We might also want to think about boot improvements on the VTi side. If anyone wants to provide status updates on bigger tasks they're working on, that would be great too. PV-on-HVM driver status and performance data on IPF might be an interesting topic. Isaku has an outstanding set of performance improvement patches we might want to discuss. I'm open to about anything, so let's start thinking about how to make it productive. Please let me know if you'll be attending as well. 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] pal_halt_light emulatefor domU TAKE3
On Thu, 2006-08-24 at 10:50 +0900, Atsushi SAKAI wrote: Status I already started testing yamahata's suggested code from yesterday night. But it does not come to 16h (currently 13h30m running is passed at 10:30 JST(+9:00)) Test Configuration is 2xDomU Linux Kernel Compile Test on 4xpCPU w/ credit scheduler. Applied. Thanks for your diligence in getting this working. 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: PATCH: cleanup - was Re: [Xen-ia64-devel] xen-ia64-unstable.hg status
On Thu, 2006-08-24 at 10:10 +0200, Tristan Gingold wrote: very small patch to avoid compile-time warning. Applied. -- 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] unaligned access handler deadlock when a user application runs in big endian mode ( psr.be is set )
All, I've got top of tree xen-ia64-unstable.hg running on my Tiger system. I'm working on getting our (Transitive's) QuickTransit dynamic binary translator working in a guest machine. QuickTransit Sparc Solaris - ia64 linux makes use of the big endian mode to speed up its translation of Sparc applications. I've tried adding a rum psr.be in all the interrupt vectors near the top and that certainly improves matters, but it also causes the unaligned access handler to believe the user app is running in little endian mode, which is not true. I've put together an example to demonstrate the issue. The source is attached below. Basically the example tries to do an unaligned access whilst in big endian mode, which when running correctly currently produces a SIGBUS ( since the Linux kernel currently has no big endian unaligned access handling ). On the Xen kernel it currently deadlocks. Comments welcome, Gareth. asmFunction.s Description: Binary data asmTest.c 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] unaligned access handler deadlock when a user application runs in big endian mode ( psr.be is set )
Gareth Knight wrote: [Thu Aug 24 2006, 07:33:07PM EDT] The source is attached below. You can't really believe anybody is going to look at that with the confidentiality notice at the top...? Aron ___ 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 driver for IPF
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
I will post patches of PV-on-HVM for IPF.
We wrote the patch under this consideration:
* Expand hvm_op hypercall
+ Introduce HVMOP_setup_shared_info_page
- A page allocated on HVM-guest OS is swapped original shared_info
page with this hypercall.
- In x86 code, original shared_info page is used after pv-on-hvm
setup with remapping feature in arch depend HYPERVISOR_memory_op.
But, we can't implement same feature for IPF, thus we select to
implement with this method.
Can you explain why you can't reuse the HYPERVISOR_memory_op hcall ?
It isn't clear for me.
In x86 code (xen/arch/x86/mm.c), it uses only virtual space of page frame
allocated by GuestOS, and remaps the vitual space to original share_info
page frame. But, we can't find same method for IPF.
Can you suggest us about the remapping method ?
About the patch:
+static int
+vmx_gnttab_setup_table(unsigned long frame_pa, unsigned long nr_frames)
+{
+struct domain *d = current-domain;
+int rc = 0, i;
+unsigned long o_grant_shared, pgaddr;
+
+if (nr_frames != NR_GRANT_FRAMES) {
+return -1;
You'd better to return -EINVAL.
I agree. I'll correct it.
+}
+o_grant_shared = (unsigned long)d-grant_table-shared;
+d-grant_table-shared = (struct grant_entry *)domain_mpa_to_imva(d,
frame_pa);
+
+/* Copy existing grant table shared into new page */
+if (o_grant_shared) {
+memcpy((void*)d-grant_table-shared,
+(void*)o_grant_shared, PAGE_SIZE * nr_frames);
You should check the result of domain_mpa_to_imva, as it could fail.
I agree. I'll try to correct it. It returns NULL if it fails, I think.
Is it correct ?
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+}
+else {
+put_page(virt_to_page(pgaddr));
+}
May create a function to be called by gnttab_setup_table and
setup_shared_info_page.
I think that these function are for only VT-i domain, thus I used
vmx_ prefix. What do you think about it ?
Thanks,
-- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] unaligned access handler deadlock when a user application runs in big endian mode ( psr.be is set )
Oops ! I see it so often its almost invisible now, will repost Thanks ! Gareth. Gareth Knight wrote: [Thu Aug 24 2006, 07:33:07PM EDT] The source is attached below. You can't really believe anybody is going to look at that with the confidentiality notice at the top...? Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Fedora-ia64-list] [FYI] FC6 kernel and latest xen
Hi, Prarit I enter BZ. Bugzilla Bug 204011: kernel unaligned access Best Regards, Akio Takebe Akio Takebe wrote: [EMAIL PROTECTED] ~]# kernel unaligned access to 0xe000187a4e1e, ip= 0xa001004fad50 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fae21 Akio, these are caused by the kernel making unaligned accesses to memory. Please enter a BZ against these and we'll try to track them down. P. kernel unaligned access to 0xe000187a4e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a4e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xe0001662921e, ip=0xa001004fad50 kernel unaligned access to 0xe0001662921e, ip=0xa001004fae21 kernel unaligned access to 0xe0001662921e, ip=0xa001004faed0 kernel unaligned access to 0xe0001662922e, ip=0xa001004fb130 kernel unaligned access to 0xe0001662921e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a5e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xedf1a61e, ip=0xa001004fad50 kernel unaligned access to 0xedf1a61e, ip=0xa001004fae21 kernel unaligned access to 0xedf1a61e, ip=0xa001004faed0 kernel unaligned access to 0xedf1a62e, ip=0xa001004fb130 kernel unaligned access to 0xedf1a61e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a501e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a501e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a501e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a502e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a501e, ip=0xa001004fb2e0 Best Regards, Akio Takebe -- Fedora-ia64-list mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/fedora-ia64-list -- Fedora-ia64-list mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/fedora-ia64-list ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] unaligned access handler deadlock when a userapplication runs in big endian mode ( psr.be is set )
Hi Gareth Handling big endian mode is an interesting topic. Frankly, In VTI side, we didn't handle big endian mode, and we knew this is an issue. I would like to look at this issue. Did you run this application on domU or VTI-domain? Thanks Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gareth Knight Sent: 2006?8?25? 7:58 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] unaligned access handler deadlock when a userapplication runs in big endian mode ( psr.be is set ) All, Repost sans confidentiality notice ! I've got top of tree xen-ia64-unstable.hg running on my Tiger system. I'm working on getting our (Transitive's) QuickTransit dynamic binary translator working in a guest machine. QuickTransit Sparc Solaris - ia64 linux makes use of the big endian mode to speed up its translation of Sparc applications. I've tried adding a rum psr.be in all the interrupt vectors near the top and that certainly improves matters, but it also causes the unaligned access handler to believe the user app is running in little endian mode, which is not true. I've put together an example to demonstrate the issue. The source is attached below. Basically the example tries to do an unaligned access whilst in big endian mode, which when running correctly currently produces a SIGBUS ( since the Linux kernel currently has no big endian unaligned access handling ). On the Xen kernel it currently deadlocks. Comments welcome, Gareth. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Weekly benchmark results [ww34]
Hi, all I will inform this week's benchmark result. The tools used now is as follows. - unixbench4.1.0 - bonnie++-1.03 - ltp-full-20060306 - iozone3_191 - lmbench-3.0-a5 TEST ENVIRONMENT Machine : Tiger4 KERN : 2.6.16.13-xen changeset: 11265:3e54734e55f3 Dom0 OS : RHEL4 U2 (no SMP) DomU OS : RHEL4 U2 (2P) No. of DomU's: 1 Sched: credit SUMMARY: - issues: - TEST RESULT unixbench4.1.0: Pass bonnie++-1.03 : Pass ltp-full-20060306 : 2/817 FAIL (see attachment) iozone3_191 : Pass lmbench-3.0-a5: Pass Thanks and best regards, Fujita and Fujitsu members ltp-domU-20060824.log 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] PV-on-HVM driver for IPF
Hi,
I'll post a new xen-hyper.patch2, whitch is modified about parameter
checking.
[EMAIL PROTECTED] wrote:
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
I will post patches of PV-on-HVM for IPF.
We wrote the patch under this consideration:
* Expand hvm_op hypercall
+ Introduce HVMOP_setup_shared_info_page
- A page allocated on HVM-guest OS is swapped original shared_info
page with this hypercall.
- In x86 code, original shared_info page is used after pv-on-hvm
setup with remapping feature in arch depend HYPERVISOR_memory_op.
But, we can't implement same feature for IPF, thus we select to
implement with this method.
Can you explain why you can't reuse the HYPERVISOR_memory_op hcall ?
It isn't clear for me.
In x86 code (xen/arch/x86/mm.c), it uses only virtual space of page frame
allocated by GuestOS, and remaps the vitual space to original share_info
page frame. But, we can't find same method for IPF.
Can you suggest us about the remapping method ?
About the patch:
+static int
+vmx_gnttab_setup_table(unsigned long frame_pa, unsigned long nr_frames)
+{
+struct domain *d = current-domain;
+int rc = 0, i;
+unsigned long o_grant_shared, pgaddr;
+
+if (nr_frames != NR_GRANT_FRAMES) {
+return -1;
You'd better to return -EINVAL.
I agree. I'll correct it.
+}
+o_grant_shared = (unsigned long)d-grant_table-shared;
+d-grant_table-shared = (struct grant_entry *)domain_mpa_to_imva(d,
frame_pa);
+
+/* Copy existing grant table shared into new page */
+if (o_grant_shared) {
+memcpy((void*)d-grant_table-shared,
+(void*)o_grant_shared, PAGE_SIZE * nr_frames);
You should check the result of domain_mpa_to_imva, as it could fail.
I agree. I'll try to correct it. It returns NULL if it fails, I think.
Is it correct ?
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+}
+else {
+put_page(virt_to_page(pgaddr));
+}
May create a function to be called by gnttab_setup_table and
setup_shared_info_page.
I think that these function are for only VT-i domain, thus I used
vmx_ prefix. What do you think about it ?
Thanks,
-- Tsunehisa Doi
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 3e54734e55f3 xen/arch/ia64/vmx/vmx_hypercall.c
--- a/xen/arch/ia64/vmx/vmx_hypercall.c Wed Aug 23 13:26:46 2006 -0600
+++ b/xen/arch/ia64/vmx/vmx_hypercall.c Fri Aug 25 11:08:18 2006 +0900
@@ -2,6 +2,7 @@
/*
* vmx_hyparcall.c: handling hypercall from domain
* Copyright (c) 2005, Intel Corporation.
+ * Copyright (c) 2006, Fujitsu Limited.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -17,6 +18,8 @@
* Place - Suite 330, Boston, MA 02111-1307 USA.
*
* Xuefei Xu (Anthony Xu) ([EMAIL PROTECTED])
+ * Tsunehisa Doi ([EMAIL PROTECTED])
+ * Tomonari Horikoshi ([EMAIL PROTECTED])
*/
#include xen/config.h
@@ -34,6 +37,94 @@
#include public/version.h
#include asm/dom_fw.h
#include xen/domain.h
+#include xen/compile.h
+#include xen/event.h
+
+static int
+vmx_gnttab_setup_table(unsigned long frame_pa, unsigned long nr_frames)
+{
+struct domain *d = current-domain;
+int rc = 0, i;
+unsigned long o_grant_shared, pgaddr;
+
+if ((nr_frames != NR_GRANT_FRAMES) || (frame_pa (PAGE_SIZE - 1))) {
+return -EINVAL;
+}
+
+pgaddr = domain_mpa_to_imva(d, frame_pa);
+if (pgaddr == NULL) {
+return -EFAULT;
+}
+
+o_grant_shared = (unsigned long)d-grant_table-shared;
+d-grant_table-shared = (struct grant_entry *)pgaddr;
+
+/* Copy existing grant table shared into new page */
+if (o_grant_shared) {
+memcpy((void*)d-grant_table-shared,
+(void*)o_grant_shared, PAGE_SIZE * nr_frames);
+/* If original page belongs to xen heap, then relinguish back
+ * to xen heap. Or else, leave to domain itself to decide.
+ */
+for (i = 0; i NR_GRANT_FRAMES; i++) {
+pgaddr = o_grant_shared + PAGE_SIZE * i;
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+}
+else {
+put_page(virt_to_page(pgaddr));
+}
+}
+}
+else {
+memset(d-grant_table-shared, 0, PAGE_SIZE * nr_frames);
+}
+return rc;
+}
+
+static int
+vmx_setup_shared_info_page(unsigned long gpa)
+{
+VCPU *vcpu = current;
+struct domain *d = vcpu-domain;
+unsigned long o_info, pgaddr;
+struct
[Xen-ia64-devel] [PATCH][RFC]xenperf hypercall pretty print TAKE 2
This patch pretty prints the hypercall section for
$xenperf -f
Each hypercall count is tagged by its name.
Reference:
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-08/msg00261.html
Signed-off-by Ken Hironaka [EMAIL PROTECTED]
diff -r 3e54734e55f3 tools/misc/xenperf.c
--- a/tools/misc/xenperf.c Wed Aug 23 13:26:46 2006 -0600
+++ b/tools/misc/xenperf.c Thu Aug 24 18:01:41 2006 +0900
@@ -10,13 +10,81 @@
* Description:
*/
-
#include xenctrl.h
#include stdio.h
#include stdlib.h
#include sys/mman.h
#include errno.h
#include string.h
+
+const char* hypercall_name_table[64]=
+{
+[__HYPERVISOR_set_trap_table] = set_trap_table,/*0*/
+[__HYPERVISOR_mmu_update] = mmu_update,/*1*/
+[__HYPERVISOR_set_gdt] = set_gdt, /*2*/
+[__HYPERVISOR_stack_switch] = stack_switch,/*3*/
+[__HYPERVISOR_set_callbacks] = set_callbacks, /*4*/
+[__HYPERVISOR_fpu_taskswitch] = fpu_taskswitch,/*5*/
+[__HYPERVISOR_sched_op_compat] = sched_op_compat, /*6*/
+[__HYPERVISOR_dom0_op] = dom0_op, /*7*/
+[__HYPERVISOR_set_debugreg] = set_debugreg,/*8*/
+[__HYPERVISOR_get_debugreg] = get_debugreg,/*9*/
+[__HYPERVISOR_update_descriptor] = update_descriptor, /*10*/
+[11] = NULL, /*11*/
+[__HYPERVISOR_memory_op] = memory_op, /*12*/
+[__HYPERVISOR_multicall] = multicall, /*13*/
+[__HYPERVISOR_update_va_mapping] = update_va_mapping, /*14*/
+[__HYPERVISOR_set_timer_op] = set_timer_op,/*15*/
+[__HYPERVISOR_event_channel_op_compat] = event_channel_op_compat, /*16 compat since 0x00030202 */
+[__HYPERVISOR_xen_version] = xen_version, /*17*/
+[__HYPERVISOR_console_io] = console_io,/*18*/
+[__HYPERVISOR_physdev_op_compat] = physdev_op_compat, /*19 compat since 0x00030202 */
+[__HYPERVISOR_grant_table_op] = grant_table_op,/*20*/
+[__HYPERVISOR_vm_assist] = vm_assist, /*21*/
+[__HYPERVISOR_update_va_mapping_otherdomain] = update_va_mapping_otherdomain, /*22*/
+[__HYPERVISOR_iret] = iret,/*23 x86 only */
+[__HYPERVISOR_vcpu_op] = vcpu_op, /*24*/
+[__HYPERVISOR_set_segment_base] = set_segment_base,/*25 x86/64 only */
+[__HYPERVISOR_mmuext_op] = mmuext_op, /*26*/
+[__HYPERVISOR_acm_op] = acm_op,/*27*/
+[__HYPERVISOR_nmi_op] = nmi_op,/*28*/
+[__HYPERVISOR_sched_op] = sched_op,/*29*/
+[__HYPERVISOR_callback_op] = callback_op, /*30*/
+[__HYPERVISOR_xenoprof_op] = xenoprof_op, /*31*/
+[__HYPERVISOR_event_channel_op] = event_channel_op,/*32*/
+[__HYPERVISOR_physdev_op] = physdev_op,/*33*/
+[__HYPERVISOR_hvm_op] = hvm_op,/*34*/
+[35] = NULL, /*35*/
+[36] = NULL, /*36*/
+[37] = NULL, /*37*/
+[38] = NULL, /*38*/
+[39] = NULL, /*39*/
+[40] = NULL, /*40*/
+[41] = NULL, /*41*/
+[42] = NULL, /*42*/
+[43] = NULL, /*43*/
+[44] = NULL, /*44*/
+[45] = NULL, /*45*/
+[46] = NULL, /*46*/
+[47] = NULL, /*47*/
+/* Architecture-specific hypercall definitions. */
+[__HYPERVISOR_arch_0] = arch_0,/*48*/
+
Re: [Xen-ia64-devel] [PATCH][RFC]xenperf hypercall pretty print TAKE 2
On Fri, 2006-08-25 at 11:51 +0900, Ken Hironaka wrote: This patch pretty prints the hypercall section for $xenperf -f Each hypercall count is tagged by its name. Hi Ken, This looks like it should be submitted to xen-devel. 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
