Re: [Xen-ia64-devel] BUG at mm.c:605
Hi Alex,
Alex Williamson wrote:
I think the issue is same as reported in the below thread.
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-09/msg00204.html
I tried to convince him, but failed.
I think that the best way is to revert the patch and we should seek
for the right fix.
I agree with Isaku's opinion. I think that the patch was preliminary
to avoid crash hypervisor.
Ok, should I simply revert xen-ia64-unstable cset 11636:3470d9cd27e5?
Basically, yes. But we can't avoid hypervisor crash during domain
destruction.
I think to modify above patch to remove VT-i domain checker like
attaced patch, until we will success to seek for the right fix.
Thanks
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 29cae9cfc9e5b8d1893dc67fc455f5fedb323805
# Parent da717c160155a99c90e91049400ef32bff2a579f
Preliminary fix to avoid hypervisor crash during domain destruction
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r da717c160155 -r 29cae9cfc9e5 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cWed Oct 18 15:27:08 2006 +0900
+++ b/xen/arch/ia64/xen/mm.cWed Oct 18 15:33:53 2006 +0900
@@ -399,11 +399,10 @@ gmfn_to_mfn_foreign(struct domain *d, un
unsigned long pte;
// This function may be called from __gnttab_copy()
- // during destruction of VT-i domain with PV-on-HVM driver.
+ // during domain destruction with VNIF copy receiver.
// ** FIXME: This is not SMP-safe yet about p2m table. **
if (unlikely(d-arch.mm.pgd == NULL)) {
- if (VMX_DOMAIN(d-vcpu[0]))
- return INVALID_MFN;
+ return INVALID_MFN;
}
pte = lookup_domain_mpa(d,gpfn PAGE_SHIFT, NULL);
if (!pte) {
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH 2/12]MCA handler support for Xen/ia64 TAKE 2
Hi Alex,
I attached updated patches for CONFIG_XEN_IA64_PERVCPU_VHPT
configuration.
I modified to read the vhpt address from vcpu-arch.vhpt_maddr.
Thanks,
KAZ
Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED]
Signed-off-by: Masaki Kanno [EMAIL PROTECTED]
Signed-off-by: Kazuhiro Suzuki [EMAIL PROTECTED]
From: Alex Williamson [EMAIL PROTECTED]
Subject: Re: [Xen-ia64-devel] [PATCH 2/12]MCA handler support for Xen/ia64 TAKE
2
Date: Mon, 16 Oct 2006 16:38:38 -0600
On Tue, 2006-10-10 at 20:02 +0900, SUZUKI Kazuhiro wrote:
+#ifdef XEN
+ // 5. VHPT
+#if VHPT_ENABLED
+ mov r24=VHPT_SIZE_LOG22
+ movl r22=VHPT_ADDR
+ mov r21=IA64_TR_VHPT
...
+#ifdef XEN
+ // 5. VHPT
+#if VHPT_ENABLED
+ mov r24=VHPT_SIZE_LOG22
+ movl r22=VHPT_ADDR
Hi Kaz,
VHPT_ADDR was just removed from the tree in this patch:
http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=685586518b2e
Can you send me a patch to apply on top of this one that removes
VHPT_ADDR? Thanks,
Alex
--
Alex Williamson HP Open Source Linux Org.
diff -r fcd746cf4647 xen/arch/ia64/linux-xen/mca_asm.S
--- a/xen/arch/ia64/linux-xen/mca_asm.S Sat Oct 14 18:10:08 2006 -0600
+++ b/xen/arch/ia64/linux-xen/mca_asm.S Wed Oct 18 14:57:07 2006 +0900
@@ -24,6 +24,9 @@
#include asm/processor.h
#include asm/mca_asm.h
#include asm/mca.h
+#ifdef XEN
+#include asm/vhpt.h
+#endif
/*
* When we get a machine check, the kernel stack pointer is no longer
@@ -50,8 +53,7 @@
*/
#ifdef XEN
#define SAL_TO_OS_MCA_HANDOFF_STATE_SAVE(_tmp) \
- movl_tmp=THIS_CPU(ia64_sal_to_os_handoff_state_addr);; \
- tpa _tmp=_tmp;; \
+ GET_THIS_PADDR(_tmp, ia64_sal_to_os_handoff_state_addr);; \
ld8 _tmp=[_tmp];; \
st8 [_tmp]=r1,0x08;;\
st8 [_tmp]=r8,0x08;;\
@@ -72,6 +74,7 @@
st8 [_tmp]=r12,0x08;; \
st8 [_tmp]=r17,0x08;; \
st8 [_tmp]=r18,0x08
+#endif /* XEN */
/*
* OS_MCA_TO_SAL_HANDOFF_STATE (SAL 3.0 spec)
@@ -101,6 +104,24 @@
* imots_sal_check_ra=Return address to location within SAL_CHECK
*
*/
+#ifdef XEN
+#define COLD_BOOT_HANDOFF_STATE(sal_to_os_handoff,os_to_sal_handoff,tmp)\
+ movltmp=IA64_MCA_COLD_BOOT; \
+ GET_THIS_PADDR(r2,ia64_sal_to_os_handoff_state_addr);; \
+ ld8 sal_to_os_handoff=[sal_to_os_handoff];; \
+ movlos_to_sal_handoff=ia64_os_to_sal_handoff_state;;\
+ dep os_to_sal_handoff = 0, os_to_sal_handoff, 60, 4;; \
+ /*DATA_VA_TO_PA(os_to_sal_handoff);;*/ \
+ st8 [os_to_sal_handoff]=tmp,8;; \
+ ld8 tmp=[sal_to_os_handoff],48;;\
+ st8 [os_to_sal_handoff]=tmp,8;; \
+ movltmp=IA64_MCA_SAME_CONTEXT;; \
+ st8 [os_to_sal_handoff]=tmp,8;; \
+ ld8 tmp=[sal_to_os_handoff],-8;;\
+ st8 [os_to_sal_handoff]=tmp,8;; \
+ ld8 tmp=[sal_to_os_handoff];; \
+ st8 [os_to_sal_handoff]=tmp;;
+#else /* XEN */
#define COLD_BOOT_HANDOFF_STATE(sal_to_os_handoff,os_to_sal_handoff,tmp)\
movltmp=IA64_MCA_COLD_BOOT; \
movlsal_to_os_handoff=__pa(ia64_sal_to_os_handoff_state); \
@@ -114,13 +135,13 @@
st8 [os_to_sal_handoff]=tmp,8;; \
ld8 tmp=[sal_to_os_handoff];; \
st8 [os_to_sal_handoff]=tmp;;
+#endif /* XEN */
#define GET_IA64_MCA_DATA(reg) \
GET_THIS_PADDR(reg, ia64_mca_data) \
;; \
ld8 reg=[reg]
-#endif /* XEN */
.global ia64_os_mca_dispatch
.global ia64_os_mca_dispatch_end
#ifndef XEN
@@ -132,7 +153,40 @@
.text
.align 16
-#ifndef XEN
+#ifdef XEN
+/*
+ * void set_per_cpu_data(void)
+ * {
+ * int i;
+ * for (i = 0; i 64; i++) {
+ * if (ia64_mca_tlb_list[i].cr_lid == ia64_getreg(_IA64_REG_CR_LID)) {
+ * ia64_set_kr(IA64_KR_PER_CPU_DATA, ia64_mca_tlb_list[i].percpu_paddr);
+ * return;
+ * }
+ * }
+ * while(1); // Endless loop on error
+ * }
+ */
+#defineSET_PER_CPU_DATA() \
+ LOAD_PHYSICAL(p0,r2,ia64_mca_tlb_list);;\
+ mov r7 = r0;\
+ mov r6 = r0;; \
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
Hi Yongkang,
Thank you for your report.
Does it output this trace back message when you detach vnif with
xm network-detach command ?
I've looked `netif_release_rx_bufs: fix me for copying receiver.'
message sometimes at vnif detaching. But I've not met domain-vti
crash.
What is the guest OS vesion ?
Thanks,
- Tsunehisa
You (yongkang.you) said:
Hi Tsunehisa,
I have tried your patch and tried the modules in VTI domains.
VBD hasn't problem. I can mount VBD hard disk xvda successfully.
But VNIF modules has problems. After I tried to insmod VNIF driver, VTI
domain crashed.
My vnif config: vif= [ 'type=ioemu, bridge=xenbr0', ' ' ]
BTW, I remake the VTI kernel with 2.6.16.
Following is the log:
$B#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=(B
[EMAIL PROTECTED] ~]# insmod xen-platform-pci.ko
PCI: Enabling device :00:03.0 (0010 - 0013)
Grant table initialized
[EMAIL PROTECTED] ~]# insmod xenbus.ko
[EMAIL PROTECTED] ~]# insmod xen-vnif.ko
[EMAIL PROTECTED] ~]# vif vif-0: 2 parsing device/vif/0/mac
netif_release_rx_bufs: fix me for copying receiver.
kernel BUG at net/core/dev.c:3073!
xenwatch[3970]: bugcheck! 0 [1]
Modules linked in: xen_vnif xenbus xen_platform_pci sunrpc binfmt_misc dm_mod
thermal processor fan container button
Pid: 3970, CPU 0, comm: xenwatch
psr : 1010081a6018 ifs : 838b ip : [a001005eec40]
Not tainted
ip is at unregister_netdevice+0x1a0/0x580
unat: pfs : 038b rsc : 0003
rnat: a00100a646c1 bsps: 0007 pr : 6941
ldrs: ccv : fpsr: 0009804c8a70433f
csd : ssd :
b0 : a001005eec40 b6 : a001000b79c0 b7 : a001bbc0
f6 : 1003e00a0 f7 : 1003e20c49ba5e353f7cf
f8 : 1003e04e2 f9 : 1003e0fa0
f10 : 1003e3b9aca00 f11 : 1003e431bde82d7b634db
r1 : a00100b34120 r2 : 0002 r3 : 00104000
r8 : 0026 r9 : 0001 r10 : e1014644
r11 : 0003 r12 : e25b7da0 r13 : e25b
r14 : 4000 r15 : a0010086f558 r16 : a0010086f560
r17 : e1d9fde8 r18 : e1d98030 r19 : e1014638
r20 : 0073 r21 : 0003 r22 : 0002
r23 : e1d98040 r24 : e1014608 r25 : e1014d80
r26 : e1014d60 r27 : 0073 r28 : 0073
r29 : r30 : r31 :
Call Trace:
[a00100011df0] show_stack+0x50/0xa0
sp=e25b7910 bsp=e25b12e0
[a001000126c0] show_regs+0x820/0x840
sp=e25b7ae0 bsp=e25b1298
[a00100037030] die+0x1d0/0x2e0
sp=e25b7ae0 bsp=e25b1250
[a00100037180] die_if_kernel+0x40/0x60
sp=e25b7b00 bsp=e25b1220
[a001000373d0] ia64_bad_break+0x230/0x480
sp=e25b7b00 bsp=e25b11f0
[a001c3c0] ia64_leave_kernel+0x0/0x280
sp=e25b7bd0 bsp=e25b11f0
[a001005eec40] unregister_netdevice+0x1a0/0x580
sp=e25b7da0 bsp=e25b1198
[a001005ef050] unregister_netdev+0x30/0x60
sp=e25b7da0 bsp=e25b1178
[a002000c5cd0] close_netdev+0x90/0xc0 [xen_vnif]
sp=e25b7da0 bsp=e25b1140
[a002000c7870] backend_changed+0x1030/0x1080 [xen_vnif]
sp=e25b7da0 bsp=e25b10a8
[a002000e5160] otherend_changed+0x160/0x1a0 [xenbus]
sp=e25b7dc0 bsp=e25b1068
[a002000e3e70] xenwatch_handle_callback+0x70/0x100 [xenbus]
sp=e25b7dc0 bsp=e25b1040
[a002000e4230] xenwatch_thread+0x330/0x3a0 [xenbus]
sp=e25b7dc0 bsp=e25b1018
[a001000b6e20] kthread+0x180/0x200
sp=e25b7e20 bsp=e25b0fd8
[a001000141b0] kernel_thread_helper+0xd0/0x100
sp=e25b7e30 bsp=e25b0fb0
[a00194c0] start_kernel_thread+0x20/0x40
sp=e25b7e30 bsp=e25b0fb0
BUG: xenwatch/3970, lock held at task exit time!
[a002000f0cf8] {xenwatch_mutex}
.. held by: xenwatch: 3970 [e25b, 110]
... acquired at: xenwatch_thread+0x1e0/0x3a0 [xenbus]
Best Regards,
Yongkang (Kangkang) [EMAIL PROTECTED](B
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
RE: [Xen-ia64-devel] Please try PV-on-HVM on IPF
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 2006年10月18日 15:56 To: You, Yongkang Cc: DOI Tsunehisa; xen-ia64-devel Subject: Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF Hi Yongkang, Thank you for your report. Does it output this trace back message when you detach vnif with xm network-detach command ? No. I didn't use above command to detach vnif. Usually I used following ways to enable vnif NIC. 1. create VTI with vif = [ '' ] 2. After VTI boot up, insert 3 related PV drivers to enable VNIF. 3. If there is a /etc/sysconfig/network-script/ifcfg-eth0, I need not do anything, VNIF eth0 will be brought up. The trace back message will happen when I just inserted vnif driver into VTI, when I used 2 NICs for VTI (1 is IOEMU, the other is VNIF). I've looked `netif_release_rx_bufs: fix me for copying receiver.' message sometimes at vnif detaching. But I've not met domain-vti crash. The crashing happened if I also use IOEMU NIC for VTI domain. The VTI vif config should like: vif = [ 'type=ioemu, bridge=xenbr0', '' ] What is the guest OS vesion ? The VTI guest OS is RHEL4u3. Thanks, - Tsunehisa Best Regards, Yongkang (Kangkang) 永康 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
You (yongkang.you) said: Does it output this trace back message when you detach vnif with xm network-detach command ? No. I didn't use above command to detach vnif. Usually I used following ways to enable vnif NIC. 1. create VTI with vif = [ '' ] 2. After VTI boot up, insert 3 related PV drivers to enable VNIF. 3. If there is a /etc/sysconfig/network-script/ifcfg-eth0, I need not do anything, VNIF eth0 will be brought up. The trace back message will happen when I just inserted vnif driver into VTI, when I used 2 NICs for VTI (1 is IOEMU, the other is VNIF). I've looked `netif_release_rx_bufs: fix me for copying receiver.' message sometimes at vnif detaching. But I've not met domain-vti crash. The crashing happened if I also use IOEMU NIC for VTI domain. The VTI vif config should like: vif = [ 'type=ioemu, bridge=xenbr0', '' ] Thanks. I'll try it. What is the guest OS vesion ? The VTI guest OS is RHEL4u3. Did you change kernel to linux-2.6.16 ? - Tsunehisa ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Please try PV-on-HVM on IPF
What is the guest OS vesion ? The VTI guest OS is RHEL4u3. Did you change kernel to linux-2.6.16 ? Yes. Or I can not even insert xen-platform.ko and xenbus.ko. ;) Best Regards, Yongkang (Kangkang) 永康 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
You (Tristan.Gingold) said: On RHEL4 U2 kernel (Linux version 2.6.9-22.EL), xen-platform-pci includes `PCI Bus :00', but it should be the leaf node, I think. To insmod xen-platform-pci, this iomem space was conflicted with the inner device, thus it can't be attached. At least RHEL4 U2 is coherent! Yes. But I do not understand where 'c200-c2000fff : PCI Bus :00' comes from. According to your lspci, there is nothing here. Maybe it was added by the ACPI table ? Thank you. I'll try to look. - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: merge pal emulator
Hi,
this patch merge the Vti and non-vti pal emulator.
Tested by booting domVTi+linux and domU.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID e6a3e55dec70d7acb9f6a8cdc4b378c75341ddb4
# Parent 06ed19691f6d770eb9cbf2a9236f02f1d016da74
Merge VTi pal emulator with Xen pal emulator.
Xen/ia64 now has only one pal and one sal emulator.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 06ed19691f6d -r e6a3e55dec70 xen/arch/ia64/vmx/pal_emul.c
--- a/xen/arch/ia64/vmx/pal_emul.c Tue Oct 17 15:49:05 2006 -0600
+++ b/xen/arch/ia64/vmx/pal_emul.c Wed Oct 18 08:12:01 2006 +0200
@@ -17,509 +17,46 @@
* this program; if not, write to the Free Software Foundation, Inc., 59 Temple
* Place - Suite 330, Boston, MA 02111-1307 USA.
*/
-
-#include asm/vmx_vcpu.h
+
+#include xen/lib.h
+#include asm/vcpu.h
+#include asm/dom_fw.h
#include asm/pal.h
#include asm/sal.h
-#include asm/dom_fw.h
-#include asm/tlb.h
-#include asm/vmx_mm_def.h
-#include xen/hypercall.h
-#include public/sched.h
-/*
- * Handy macros to make sure that the PAL return values start out
- * as something meaningful.
- */
-#define INIT_PAL_STATUS_UNIMPLEMENTED(x) \
- { \
- x.status = PAL_STATUS_UNIMPLEMENTED; \
- x.v0 = 0;\
- x.v1 = 0;\
- x.v2 = 0;\
- }
-
-#define INIT_PAL_STATUS_SUCCESS(x) \
- { \
- x.status = PAL_STATUS_SUCCESS; \
- x.v0 = 0;\
- x.v1 = 0;\
- x.v2 = 0;\
- }
-
-static void
-get_pal_parameters(VCPU *vcpu, u64 *gr29, u64 *gr30, u64 *gr31) {
-
- vcpu_get_gr_nat(vcpu,29,gr29);
- vcpu_get_gr_nat(vcpu,30,gr30);
- vcpu_get_gr_nat(vcpu,31,gr31);
-}
-
-static void
-set_pal_result(VCPU *vcpu,struct ia64_pal_retval result) {
-
- vcpu_set_gr(vcpu,8, result.status,0);
- vcpu_set_gr(vcpu,9, result.v0,0);
- vcpu_set_gr(vcpu,10, result.v1,0);
- vcpu_set_gr(vcpu,11, result.v2,0);
-}
-
-static void
-set_sal_result(VCPU *vcpu,struct sal_ret_values result) {
-
- vcpu_set_gr(vcpu,8, result.r8,0);
- vcpu_set_gr(vcpu,9, result.r9,0);
- vcpu_set_gr(vcpu,10, result.r10,0);
- vcpu_set_gr(vcpu,11, result.r11,0);
-}
-
-static struct ia64_pal_retval
-pal_cache_flush(VCPU *vcpu) {
- u64 gr28,gr29, gr30, gr31;
+void
+pal_emul(struct vcpu *vcpu)
+{
+ u64 gr28, gr29, gr30, gr31;
struct ia64_pal_retval result;
- get_pal_parameters(vcpu, gr29, gr30, gr31);
- vcpu_get_gr_nat(vcpu, 28, gr28);
+ vcpu_get_gr_nat(vcpu, 28, gr28); //bank1
- /* Always call Host Pal in int=1 */
- gr30 = gr30 ~0x2UL;
+ /* FIXME: works only for static calling convention ? */
+ vcpu_get_gr_nat(vcpu, 29, gr29);
+ vcpu_get_gr_nat(vcpu, 30, gr30);
+ vcpu_get_gr_nat(vcpu, 31, gr31);
- /*
- * Call Host PAL cache flush
- * Clear psr.ic when call PAL_CACHE_FLUSH
- */
- result = ia64_pal_call_static(gr28 ,gr29, gr30, gr31, 1);
+ perfc_incrc(vmx_pal_emul);
+ result = xen_pal_emulator (gr28, gr29, gr30, gr31);
- /* If host PAL call is interrupted, then loop to complete it */
-// while (result.status == 1)
-// ia64_pal_call_static(gr28 ,gr29, gr30, result.v1, 1LL);
-//
- if (result.status != 0)
- panic_domain(vcpu_regs(vcpu), PAL_CACHE_FLUSH ERROR,
- status %ld, result.status);
-
- return result;
-}
-
-static struct ia64_pal_retval
-pal_vm_tr_read(VCPU *vcpu) {
- struct ia64_pal_retval result;
-
- INIT_PAL_STATUS_UNIMPLEMENTED(result);
-
- return result;
-}
-
-static struct ia64_pal_retval
-pal_prefetch_visibility(VCPU *vcpu) {
- /* Due to current MM virtualization algorithm,
- * We do not allow guest to change mapping attribute.
- * Thus we will not support PAL_PREFETCH_VISIBILITY
- */
- struct ia64_pal_retval result;
-
- INIT_PAL_STATUS_UNIMPLEMENTED(result);
-
- return result;
-}
-
-static struct ia64_pal_retval
-pal_platform_addr(VCPU *vcpu) {
- struct ia64_pal_retval result;
-
- INIT_PAL_STATUS_SUCCESS(result);
-
- return result;
-}
-
-static struct ia64_pal_retval
-pal_halt(VCPU *vcpu) {
- //bugbug: to be implement.
- struct ia64_pal_retval result;
-
- INIT_PAL_STATUS_UNIMPLEMENTED(result);
-
- return result;
-}
-
-static struct ia64_pal_retval
-pal_halt_light(VCPU *vcpu) {
- struct ia64_pal_retval result;
-
- if (!is_unmasked_irq(vcpu))
- do_sched_op_compat(SCHEDOP_block, 0);
-
- INIT_PAL_STATUS_SUCCESS(result);
-
- return result;
-}
-
-static struct ia64_pal_retval
-pal_cache_read(VCPU *vcpu) {
- struct ia64_pal_retval result;
-
- INIT_PAL_STATUS_UNIMPLEMENTED(result);
-
- return result;
-}
-
-static struct ia64_pal_retval
-pal_cache_write(VCPU *vcpu) {
- struct ia64_pal_retval result;
-
- INIT_PAL_STATUS_UNIMPLEMENTED(result);
-
- return result;
-}
-
-static struct ia64_pal_retval
-pal_bus_get_features(VCPU *vcpu) {
- struct ia64_pal_retval result;
-
- INIT_PAL_STATUS_UNIMPLEMENTED(result);
-
- return result;
-}
-
-static struct ia64_pal_retval
-pal_cache_summary(VCPU *vcpu) {
- struct ia64_pal_retval result;
-
- INIT_PAL_STATUS_UNIMPLEMENTED(result);
-
- return result;
-}
-
-static struct ia64_pal_retval
-pal_cache_init(VCPU *vcpu) {
- struct ia64_pal_retval result;
-
-
[Xen-ia64-devel][PATCH] a bug fix about accelerating MOV_TO_RR
Signed-off-by: Anthony Xu [EMAIL PROTECTED] Anthony fix_acce_mov_to_rr.patch Description: fix_acce_mov_to_rr.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel][PATCH]add two more PAL call emulations
Add two more PAL call emulations, These are needed for FC6 Signed-off-by, Anthony Xu [EMAIL PROTECTED] Anthony boot_fc6.patch Description: boot_fc6.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH 6/12]MCA handler support for Xen/ia64 TAKE 2
On Mon, 2006-10-16 at 14:46 +0900, SUZUKI Kazuhiro wrote: Hi Alex, I modified to insert is_running_on_xen() and I attached this patch. Hi Kaz, Does this build for you? I get this: In file included from include/asm-ia64/mca.h:20, from arch/ia64/kernel/asm-offsets.c:16: include/asm/sal.h: In function 'ia64_sal_get_state_info': include/asm/sal.h:702: error: invalid storage class for function 'ia64_sal_get_state_info_size' include/asm/sal.h:704: warning: implicit declaration of function 'ia64_sal_get_state_info_size' include/asm/sal.h: At top level: include/asm/sal.h:726: error: conflicting types for 'ia64_sal_get_state_info_size' include/asm/sal.h:704: error: previous implicit declaration of 'ia64_sal_get_state_info_size' was here make[1]: *** [arch/ia64/kernel/asm-offsets.s] Error 1 make: *** [prepare0] Error 2 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 more PAL call emulations
Hi Anthony, Can you tell me what FC6 problem you fix with this patch? Thanks, Yoshi -- Xu, Anthony [EMAIL PROTECTED] wrote: Add two more PAL call emulations, These are needed for FC6 Signed-off-by, Anthony Xu [EMAIL PROTECTED] Anthony ___ 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, Aron and Juan We fix this bug. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204011 Please apply the following patch. http://xenbits.xensource.com/xen-unstable.hg?cs=797430d25f1b Best Regards, Akio Takebe 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 -- 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][PATCH]add two more PAL call emulations
Hi Yoshi, This patch was done about one month again, and I forgot to check in. Before, these two PAL calls were handled by Guest Firmware, While the Guest Firmware is old, But new IPF processor has split L2 cache, So new processor has five caches, 2 L1 cache, 2 L2 cache, 1 L3 cache, Old processor has four caches, 2 L1 cache, 1 L2 cache, 1 L3 cache, The Guest Firmware will return 4 caches. FC6 will get these information to initiate Cache, if use old implementation, There are issues. We will send the new Firmware out. Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 2006年10月19日 7:23 To: Xu, Anthony; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel][PATCH]add two more PAL call emulations Hi Anthony, Can you tell me what FC6 problem you fix with this patch? Thanks, Yoshi -- Xu, Anthony [EMAIL PROTECTED] wrote: Add two more PAL call emulations, These are needed for FC6 Signed-off-by, Anthony Xu [EMAIL PROTECTED] Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] BUG at mm.c:605
On Wed, 2006-10-18 at 16:03 +0900, DOI Tsunehisa wrote: Hi Alex, Alex Williamson wrote: Ok, should I simply revert xen-ia64-unstable cset 11636:3470d9cd27e5? Basically, yes. But we can't avoid hypervisor crash during domain destruction. I think to modify above patch to remove VT-i domain checker like attaced patch, until we will success to seek for the right fix. This seems worse. Instead of having an identifiable crash footprint, the system just hangs with this patch. 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] Re: PATCH: makes XEN virtual mapping more flexible
On Wed, 2006-10-18 at 11:53 +0200, Tristan Gingold wrote: Hi, By making xen virtual mapping more flexible I am able to run Xen within XenVTi. This is very useful to debug Xen and also to test the VTi code. Tested by running domU and domVTI. Hi Tristan, I get segfaults with this patch on both domVTI and domU. My RHEL4U3 VTI domain hit errors in the init scripts and my SMP domU couldn't complete a kernel compile. 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] Re: PATCH: merge pal emulator
On Wed, 2006-10-18 at 10:52 +0200, Tristan Gingold wrote: Hi, this patch merge the Vti and non-vti pal emulator. 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] Re: PATCH: fix VTI VHPT long format
On Wed, 2006-10-18 at 14:47 +0200, Tristan Gingold wrote: Hi, Currently Xen/VTi doesn't inject the right interruption in case of fault when vhpt long format is used. This patch fixes this bug. Using this patch and the previous one, I was able to log on linux within xen within xen/vti! Cool stuff. I hope we can get the other patch debugged to enable this. I applied this one. 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] a bug fix about accelerating MOV_TO_RR
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]add two more PAL call emulations
On Thu, 2006-10-19 at 00:16 +0800, Xu, Anthony wrote: Add two more PAL call emulations, These are needed for FC6 I think this patch is unnecessary in xen-ia64-unstable.hg with Tristan's merging of the PAL emulators. 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] crash on xen-ia64-unstable 11810:fcd746cf4647
On Wed, 2006-10-18 at 11:42 +0900, Akio Takebe wrote: Hi, Alex Yes, you're right. I added the patches for this. 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] Please try PV-on-HVM on IPF
Hi Yongkang, My name is Takanori Kasai. I receive your report, and am investigating the following problem. You (yongkang.you) said: The trace back message will happen when I just inserted vnif driver into VTI, when I used 2 NICs for VTI (1 is IOEMU, the other is VNIF). I've looked `netif_release_rx_bufs: fix me for copying receiver.' message sometimes at vnif detaching. But I've not met domain-vti crash. The crashing happened if I also use IOEMU NIC for VTI domain. The VTI vif config should like: vif = [ 'type=ioemu, bridge=xenbr0', '' ] Thanks. I'll try it. I was able to confirm this problem occurred in the same environment. (changeset :11810 ) We continue and investigate this problem. You (yongkang.you) said: 2. After insert VNIF driver, VTI kernel often calls trace when running applications (kudzu, vi etc.). This problem doesn't occur as long as we have operated up to now. How many times has this problem occurred in you up to now? Could you teach to me a little more in detail? Thanks, - Takanori Kasai ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
