[Xen-ia64-devel] [PATCH]Allow different config file for xenlinux on same arch
Currently there is no generic configure file to compile xenlinux on ia64, since there're several different system types like HP-ZX, DIG, etc. Current Makefile can't meet this need and default one (xen0_defconfig_ia64) is only for HP-ZX type. Hence, this patch can append an additional param to configuration file name to differentiate system types when make. For example, we can use make world XEN_SYSTYPE=dig to compile, and if a config file named as xen0_defconfig_ia64dig exists under arch/xen/configs, it will be copied to override xen0_defconfig_ia64 before real compilation.. If no value for this option, it use default configure file for their archs. Configuration file is not attached here. If this approach is an agreed approach to solve such requirement, we will check in the config file in another mail. Signed-off-by Zhang Xiantao [EMAIL PROTECTED] Signed-off-by Tian Kevin [EMAIL PROTECTED] diff -r 0255f48b757f Makefile --- a/Makefile Sun Dec 4 19:12:00 2005 +++ b/Makefile Wed Dec 14 17:35:04 2005 @@ -10,7 +10,7 @@ # Export target architecture overrides to Xen and Linux sub-trees. ifneq ($(XEN_TARGET_ARCH),) SUBARCH := $(subst x86_32,i386,$(XEN_TARGET_ARCH)) -export XEN_TARGET_ARCH SUBARCH +export XEN_TARGET_ARCH SUBARCH XEN_SYSTYPE endif # Default target must appear before any include lines diff -r 0255f48b757f buildconfigs/mk.linux-2.6-xen --- a/buildconfigs/mk.linux-2.6-xen Sun Dec 4 19:12:00 2005 +++ b/buildconfigs/mk.linux-2.6-xen Wed Dec 14 17:35:04 2005 @@ -30,7 +30,7 @@ CONFIG_VERSION=$$(sed -ne 's/^EXTRAVERSION = //p' $(LINUX_DIR)/Makefile); \ [ -r $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) ] \ cp $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) $(LINUX_DIR)/.config \ - || cp $(LINUX_DIR)/arch/xen/configs/$(EXTRAVERSION)_defconfig_$(XEN_TARGET_ARC H) \ + || cp $(LINUX_DIR)/arch/xen/configs/$(EXTRAVERSION)_defconfig_$(XEN_TARGET_ARC H)$(XEN_SYSTYPE) \ $(LINUX_DIR)/.config # See if we need to munge config to enable PAE $(MAKE) CONFIG_FILE=$(LINUX_DIR)/.config -f buildconfigs/Rules.mk config-update-pae Zhang Xiantao CSD-OTC PRC Virtualization Intel (China) Limited xen0_config.patch Description: xen0_config.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Help about a Kernel panic with Xen 3.0.0 onaTiger system
Hi Philippe, I think you used the default CSet 8241 of Xen3.0.Several patches has been checked into Xen3.0testing tree. The latest CSet should be 8269 which has been included tiger's configuration file Fred mentioned. Maybe you can use hg co -C to get the latest CSet to try. Thanks Zhang Xiantao CSD-OTC PRC Virtualization Intel (China) Limited -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yang, Fred Sent: 2006年1月7日 0:35 To: Philippe Berthault; Xen-IA64-Devel Subject: RE: [Xen-ia64-devel] Help about a Kernel panic with Xen 3.0.0 onaTiger system Philippe, This is because config file in Xen 3.0 does not work for Tiger system. You can try Cset#8437 from http://xenbits.xensource.com/ext/xen-ia64-unstable.hg the config file has been validated to work for Tiger4 -Fred Philippe Berthault wrote: I've tried Xen 3.0.0 (testing release) on a Tiger system (2 Itanium processors and 1 GB memory) but the boot is failed with a KERNEL PANIC.. I'm using ELILO v3.5 pre2 which supports the vmm directive. The Linux used in domain0 is a RHEL-AS4, update 1. Anyone has an idea on what is the problem ? Thanks. MY ELILO ENTRY: == image=vmlinuz-2.6.12.6-xen0 label=xen vmm=xen-3.0.0.gz initrd=initrd-2.6.12.6-xen0.img read-only append=com2=115200,8n1 console=com2 sched=bvt -- nomca console=ttyS1,115200 console=tty0 root=LABEL=/1234 THE BOOT TRACE FROM THE SERIAL LINE: == Uncompressing Linux... done Loading file initrd-2.6.12.6-xen0.img...done Loading file vmlinuz-2.6.12.6-xen0...done Uncompressing... done __ ___ ___ ___ \ \/ /___ _ __ |___ / / _ \ / _ \ \ // _ \ '_ \|_ \| | | | | | | / \ __/ | | | ___) | |_| | |_| | /_/\_\___|_| |_| |(_)___(_)___/ http://www.cl.cam.ac.uk/netos/xen University of Cambridge Computer Laboratory Xen version 3.0.0 ([EMAIL PROTECTED]) (version gcc 3.4.3 20050227 (Red Hat 3.4.3-22.1)) mar d..c 20 15:27:03 CET 2005 Latest ChangeSet: unavailable (XEN) xen image pstart: 0x400, xenheap pend: 0x800 (XEN) efi.trim_top: ignoring 4KB of memory at 0x0 due to granule hole at 0x0 (XEN) efi.trim_top: ignoring 24KB of memory at 0x1000 due to granule hole at 0x0 (XEN) efi.trim_top: ignoring 8KB of memory at 0x7000 due to granule hole at 0x0 (XEN) efi.trim_top: ignoring 484KB of memory at 0x9000 due to granule hole at 0x0 (XEN) efi.trim_top: ignoring 4KB of memory at 0x84000 due to granule hole at 0x0 (XEN) efi.trim_top: ignoring 108KB of memory at 0x85000 due to granule hole at 0x0 (XEN) efi.trim_bottom: ignoring 15360KB of memory at 0x10 due to granule hole at 0x0 (XEN) ready to move Dom0 to 0x800 with len b7c460...ready to move initrd to 0x8b8 with len 13e4f5...Done (XEN) find_memory: efi_memmap_walk returns max_page=ffb6 (XEN) Before heap_start: 0xf40e4960 (XEN) After heap_start: 0xf40ec000 (XEN) Init boot pages: 0x100 - 0x400. (XEN) Init boot pages: 0x800 - 0x3c77e010. (XEN) Init boot pages: 0x3c77e070 - 0x3c781f7f. (XEN) Init boot pages: 0x3c781fd2 - 0x3c785000. (XEN) Init boot pages: 0x3c8c34f5 - 0x3c8cc010. (XEN) Init boot pages: 0x3c8cc850 - 0x3d8b4000. (XEN) Init boot pages: 0x3d90 - 0x3fa0. (XEN) Init boot pages: 0x3fe98000 - 0x3fed8000. (XEN) System RAM: 1001MB (1026000kB) (XEN) size of frame_table: 4608kB (XEN) alloc_dom0: starting (initializing 512 MB...) (XEN) alloc_dom0: dom0_start=0800 (XEN) Xen heap: 63MB (64592kB) (XEN) ACPI: RSDP (v002 INTEL ) @ 0x3ff98000 (XEN) ACPI: XSDT (v001 INTEL SR870BH2 0x01072002 MSFT 0x00010013) @ 0x3ff98090 (XEN) ACPI: FADT (v003 INTEL SR870BH2 0x01072002 MSFT 0x00010013) @ 0x3ff98138 (XEN) ACPI: MADT (v001 INTEL SR870BH2 0x01072002 MSFT 0x00010013) @ 0x3ff98230 (XEN) ACPI: DSDT (v001 Intel SR870BH2 0x MSFT 0x010d) @ 0x (XEN) SAL 3.1: Intel Corp SR870BH2 version 3.0 (XEN) SAL Platform features: BusLock (XEN) avail:0x1180c600, status:0x600,control:0x1180c000, vm?0x0 (XEN) No VT feature supported. (XEN) cpu_init: current=f40a4000, current-domain-arch.mm= (XEN) vhpt_init: vhpt size=0100, align=0100 (XEN) vhpt_init: vhpt paddr=0500, end=05ff (XEN) ACPI: Local APIC address 0xe800fee0 (XEN) ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00] lsapic_eid[0x00] enabled) (XEN) CPU 0 (0x) enabled (XEN) ACPI: [APIC:0x07] ignored 1 entries of 2 found (XEN) ACPI: IOSAPIC (id[0x0] address[fec0] gsi_base[0]) (XEN) ACPI: IOSAPIC (id[0x1] address[fec1] gsi_base[24]) (XEN) ACPI: IOSAPIC (id[0x2] address[fec2] gsi_base[48]) (XEN) ACPI: IOSAPIC (id[0x3] address[fec3] gsi_base[72
[Xen-ia64-devel] [Knowhow] Enable network of VTi domian(FYI)
Hi all, Currently, due to no implementation for VNIF driver in Xen0, So the network of VTi domain can't work with the latest configuration. This is a knowhow for enabling it with a legacy mode which directly connects bridge rather than through vnif. 1. copy network-bridge(attachment) /etc/xen/scripts/network-bridge --overwrite the old one. 2. Enbale the NIC option in VTi's configuration file. # Optionally define mac and/or bridge for the network interfaces. # Random MACs are assigned if not given. #vif = [ 'type=ioemu, mac=00:16:3e:00:00:11, bridge=xenbr0' ] # type=ioemu specify the NIC is an ioemu device not netfront vif = [ 'type=ioemu, bridge=xenbr0' ] Enable this line . # for multiple NICs in device model, 3 in this example #vif = [ 'type=ioemu, bridge=xenbr0', 'type=ioemu', 'type=ioemu'] -- BTW, if you don't want to enable network of VTi domain, had better disable this line in case that it may bring some side effect such as wasting more time for probing network when starting VTi domain and so on. 3. Xend start 4. Create VTi domain. Thanks! Zhang Xiantao CSD-OTC PRC Virtualization Intel (China) Limited network-bridge Description: network-bridge ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Clean up warnings related to VTi code.
Hi Kan, This patch was made several days ago, and the file xen/include/xen/hypercall.h didn't exist then, so I couldn’t find this issue before sending out. This issue doesn't impact compiling, and I will send out a small patch to fix it. Thanks very much! Xiantao CSD-OTC PRC Virtualization Intel (China) Limited -Original Message- From: Masaki Kanno [mailto:[EMAIL PROTECTED] Sent: 2006年2月27日 8:52 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Clean up warnings related to VTi code. Hi Xiantao/Kevin, Sorry. it is too late, but I have one comment. extern do_sched_op() is declared in xen/include/xen/hypercall.h. diff -r 111af742e414 xen/arch/ia64/vmx/vmx_hypercall.c --- a/xen/arch/ia64/vmx/vmx_hypercall.c Sun Feb 19 04:25:31 2006 +++ b/xen/arch/ia64/vmx/vmx_hypercall.c Fri Feb 24 10:16:17 2006 @@ -31,6 +31,11 @@ #include xen/mm.h #include xen/multicall.h #include xen/hypercall.h +#include public/version.h +#include asm/dom_fw.h +#include xen/domain.h + +extern long do_sched_op(int cmd, unsigned long arg); Best regards, Kan Zhang, Xiantao wrote: Hi Dan/Alex, These two patches intend to clean up lots of warnings related to VTi code. 1. clean_up_warnings_c_file.patch removes most of the warnings such as incompatible assignment, unused variables, return value type of some functions and so on. 2. clean_up_warnings_header_file.patch adds some functions' prototype declaration in corresponding header file and removes issues redefinition of some macros. Currently lots of warnings even errors have impacted debugging severely, so it's time to solve this issue. Please help to check in. Signed-off-by : Zhang Xiantao [EMAIL PROTECTED] Signed-off-by : Kevin Tian[EMAIL PROTECTED] Thanks Xiantao Zhang CSD-OTC PRC Virtualization Intel (China) Limited __ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]Guarantee VTi guest can get correct frequency base
Because some platforms don't implement pal_freq_base call in PAL, in
this
case, call host SAL sal_freq_base instead to get correct freqency base
value.
diff -r 5e751dddf4d0 xen/arch/ia64/vmx/pal_emul.c
--- a/xen/arch/ia64/vmx/pal_emul.c Tue Feb 28 17:24:03 2006
+++ b/xen/arch/ia64/vmx/pal_emul.c Mon Mar 6 15:16:20 2006
@@ -20,6 +20,7 @@
#include asm/vmx_vcpu.h
#include asm/pal.h
+#include asm/sal.h
static void
get_pal_parameters (VCPU *vcpu, UINT64 *gr29,
@@ -182,8 +183,18 @@
static struct ia64_pal_retval
pal_freq_base(VCPU *vcpu){
struct ia64_pal_retval result;
+struct ia64_sal_retval isrv;
PAL_CALL(result,PAL_FREQ_BASE, 0, 0, 0);+if(result.v0 == 0){
//PAL_FREQ_BASE may not be implemented in some platforms, call SAL
instead.
+SAL_CALL(isrv, SAL_FREQ_BASE,
+SAL_FREQ_BASE_PLATFORM, 0, 0, 0, 0, 0, 0);
+result.status = isrv.status;
+result.v0 = isrv.v0;
+result.v1 = result.v2 =0;
+}
return result;
}
Thanks
Xiantao
CSD-OTC PRC Virtualization
Intel (China) Limited
ensure_freq_base.patch
Description: ensure_freq_base.patch
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Remove the last compile warnings
Hi Alex, Sorry, I remembered that I have added it to repository, but didn't diffed to the patch file. So I attached it. I think it is necessary to add this header file to solve some warnings and for future extension. Thanks -Xiantao -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年3月14日 12:25 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Remove the last compile warnings On Sun, 2006-03-12 at 15:29 +0800, Zhang, Xiantao wrote: Hi Dan/Alex This patch intends to remove the last warnings(C code) when compile. Currently due to lack of header files corresponding to the c file, some function declarations have to be placed in the file which refers to them. It seems that we should add some header files to solve it in future. Hi Xiantao, Looks like a good start, but it doesn't build for me: gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O2 -iwithprefix include -Wall -fomit-frame-pointer -I/opt/xen/include -D__KERNEL__ -I/opt/xen/include/asm-ia64 -I/opt/xen/include/asm-ia64/linux -I/opt/xen/include/asm-ia64/linux -I/opt/xen/include/asm-ia64/linux-xen -I/opt/xen/include/asm-ia64/linux-null -I/opt/xen/arch/ia64/linux -I/opt/xen/arch/ia64/linux-xen -DIA64 -DXEN -DLINUX_2_6 -DV_IOSAPIC_READY -ffixed-r13 -mfixed-range=f12-f15,f32-f127 -g -g -D__XEN__ -DNDEBUG -c vmx/vmx_init.c -o vmx_init.o vmx/vmx_init.c:54:25: asm/vlsapic.h: No such file or directory vmx/vmx_init.c: In function `vmx_setup_platform': vmx/vmx_init.c:440: warning: implicit declaration of function `vmx_virq_line_init' make[1]: *** [vmx_init.o] Error 1 Was vlsapic.h supposed to be added with this patch? It builds w/o the include added to vmx_init.c. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab vlsapic.h Description: vlsapic.h ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Create 2nd XenU fail after destroy 1st one
I met the same issue. Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of You, Yongkang Sent: 2006年3月16日 17:20 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] Create 2nd XenU fail after destroy 1st one Hi all, I am very glad to see xm destroy xenU will release memory. But when I try this feature, I found I couldn't create 2nd xenU successfully. I do the following steps: 1. boot Xen0 2. create XenU 3. After xenU boot up, use poweroff in xenU to kill xenU. 4. create 2nd XenU 5. when 2nd XenU boot up to start udev, xenU stop to boot and serial port kept reporting bad hyperprivop. (please see the attachment) If I destroy the 2nd xenU, the whole system seems hang. I catch this issue in Cset 9268. 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] [PATCH] XEN: fixed a vcpu_translate bug
Great! This patch can fix the two DomU creates issue. Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Xu, Anthony Sent: 2006年3月17日 11:22 To: Xu, Anthony; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH] XEN: fixed a vcpu_translate bug Please desert the old one and use this new one Thanks, -Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Xu, Anthony Sent: 2006年3月17日 10:17 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH] XEN: fixed a vcpu_translate bug There are some below code segments in guest OS 1. Rsm psr.dt ... 2. itc.d r18 ... 3. rfi After executing instruction 1, domain is in metaphysical mode. When executing instruction 2, VMM gets control to emulate this instruction. Firstly VMM will try to get opcode, which may trigger a tlb miss. At this time domain is in metaphysical mode and the fault address is in region 5. vcpu_translate handles this as normal guest metaphysical mode. It's not correct; sometimes this will make dom0 hang. cpu_translate should handle this situation as if guest is not in metaphysical mode. Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, -Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Create 2nd XenU fail after destroy 1st one
Anthony's vcpu_translate patch can fix this issue :) Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Akio Takebe Sent: 2006年3月16日 18:28 To: You, Yongkang; xen-ia64-devel@lists.xensource.com; Tristan Gingold Subject: RE: [Xen-ia64-devel] Create 2nd XenU fail after destroy 1st one Hi, Yongkang and all I have reproduced your problem. Hmm... I look like this fault is occurred at srlz instruction. I try to debug it. # Do everyone think xen's printf is buggy? My environment: Machine : Tiger4 OS: RHEL4 Update2 gestOS: RHEL4 Update2 How to reproduce 1. xend start 2. xm create domU 3. xm console domU - and hit poweroff command. 4. xm create domU then call trace is happend in xm dmesg. 5. xm destroy domU - then system hang up... Best Regards, Akio Takebe Hi Akio, I do poweroff in XenU to kill it. It means xenU has been booted up. This should more than 20 seconds. :) Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006ト・ヤツ16ネユ 17:42 To: You, Yongkang; xen-ia64-devel@lists.xensource.com; Tristan Gingold Subject: Re: [Xen-ia64-devel] Create 2nd XenU fail after destroy 1st one Hi, YongKang and Tristan I suspect this error may be happened by too early destroy. Please try to create domU after waiting about 20 sec. 1. boot Xen0 2. create XenU 3. sleep 20 3. destroy xenU 4. sleep 20 5. create 2nd XenU 6. sleep 20 7. destroy 2nd XenU Best Regards, Akio and Kan Hi all, I am very glad to see xm destroy xenU will release memory. But when I try this feature, I found I couldn't create 2nd xenU successfully. I do the following steps: 1. boot Xen0 2. create XenU 3. After xenU boot up, use poweroff in xenU to kill xenU. 4. create 2nd XenU 5. when 2nd XenU boot up to start udev, xenU stop to boot and serial port kept reporting bad hyperprivop. (please see the attachment) If I destroy the 2nd xenU, the whole system seems hang. I catch this issue in Cset 9268. Best Regards, Yongkang (Kangkang) ・筵ソ・ス・ェ ---text/plain-- - ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] (no subject)
This patch fixes VTI domain breaking issue caused by cset 9231. Root cause: cset 9231 save the ioemu vnif info into the xenstore, which cause control panel to wait for the VNIF backend device. Unfortunately, ia64 dom0 vnif backend is not ready currently due to the p2m issue. In this case, control panel will get VNIF timeout error and stop domain creation. What patch do: Since vnif backend will not be ready soon, this patch bypass this issue by adding backend=no option in control panel. When ia64 dom0 vnif backend is ready, we can safely remove this patch. Thanks -Xiantao fix_vti_qumu_block.patch Description: fix_vti_qumu_block.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fixed VTI domain destruction
Hi Masaki, Two domain destroy issue has been fixed. The patch will be sent out next week. Your destroy patch is very helpful to community developers :) Thanks Best regards -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of You, Yongkang Sent: 2006年3月23日 16:04 To: Masaki Kanno Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH] Fixed VTI domain destruction Masaki, Your patch is really important and great helpful! Needn't sorry. ;) I am playing some auto testing to try to give more accurate result in time. I also found another similar bug before that patch. If I create 1 xenU and 1 VTI, destroying xenU will cause the whole system hang. Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: Masaki Kanno [mailto:[EMAIL PROTECTED] Sent: 2006年3月23日 15:29 To: You, Yongkang Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Fixed VTI domain destruction Hi Yongkang, I'm sorry. I was hasty. I carried out a test to repeat that created/destroyed only one VTI domain. I don't know the cause why a system was hung up. Best regards, Kan You, Yongkang wrote: Hi Masaki, It is a great patch! I have tried the latest Cset about the destroying VTI Domain. But a bug induced in. :) If 1 VTI domain, it is okay. But if 2 VTI domain is created, destroy 1 VTI will hang whole system. Best Regards, Yongkang (Kangkang) 喟慎 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Masaki Kanno Sent: 2006定3��22�� 20:24 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH] Fixed VTI domain destruction Hi, This patch fixed the VTI domain destruction processing. I tested creation/destruction domU. The domU which I tested is VTI domain and non VTI domain. There was not the memory leak issue, and VTI domain is not left in a zombie state. Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan ___ 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 domainU boot when VTi domain exists
Sorry for ugly alignment. Maybe this one will be better:) This patch intends to fix domainU boot after VTi domain booted up. Currently domainU can't boot after domain VTi booted up. The root cause is when VTi domain exists, after DomU createing and being scheduled for first time, context_switch won't be executed completely but through another execution path to leave kernel. So iva and pta can't be switched to domU in this case. This will lead to LP's(run domU) iva and pta point to VTi domain's ivt and pta. So when DomainU boots, domain VTi and domainU will hang on one LP. Thanks -Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix domainU boot when VTi domainexists
Hi Alex, We are sure this patch has no problem except indent issue. According to logic, it is necessary in schedule_tial to boot XenU when VTi exists. Insteadly, It exposes another vhpt_flush bug in smp environment. We will explain it in detail in next patch. Note: This patch maybe have confilict with Anthony's hash_vtlb patch due to modifying the same file. Please help to make them consistent handly:) Thanks -Xiantao -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年3月28日 23:39 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH] Fix domainU boot when VTi domainexists On Tue, 2006-03-28 at 13:09 +0800, Zhang, Xiantao wrote: Sorry for ugly alignment. Maybe this one will be better:) This patch intends to fix domainU boot after VTi domain booted up. Currently domainU can't boot after domain VTi booted up. The root cause is when VTi domain exists, after DomU createing and being scheduled for first time, context_switch won't be executed completely but through another execution path to leave kernel. So iva and pta can't be switched to domU in this case. This will lead to LP's(run domU) iva and pta point to VTi domain's ivt and pta. So when DomainU boots, domain VTi and domainU will hang on one LP. I'm seeing a regression in domU reboot support w/ this patch. When I reboot domU, I only get this far: (XEN) efi.reset_system called ###allocating rid_range, domain f7ffa1b8: starting_rid=8, ending_rid=c (XEN) arch_domain_create: domain=f7ffa1b8 (XEN) arch_set_info_guest (XEN) sync_split_caches ignored for CPU with no split cache (XEN) ACPI 2.0=0x698domain mem: type=2, attr=0x8, range=[0x-0x0010) (1MB) (XEN) domain mem: type=13, attr=0x8, range=[0x0010-0x0020) (1MB) (XEN) domain mem: type=7, attr=0x8, range=[0x0020-0x3fff4000) (1021MB) (XEN) domain mem: type=12, attr=0x1, range=[0x0c00-0x0000) (63MB) (XEN) domain mem: type=0, attr=0x0, range=[0x-0x) (0MB) (XEN) initrd start 0x0 initrd size 0x0 (XEN) ia64_handle_reflection: unhandled vector=0x1f This leaves domU in a running state, but there's no console output and trying to destroy it with xm destroy hangs the box. Also, schedule_tail() is a tab indented function, please try to maintain consistency with the existing code when making modifications. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab fix_domU_boot_after_vti.patch Description: fix_domU_boot_after_vti.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Fix domain reboot bug
Actually domain reboot issue is not caused by our previous patch to solve schedule_tail, which instead helps to find a severe HOST_SMP plus domain destroy bug. The major reason is that currently VHPT table for dom0/domU is per LP, while domain destroy only issues vhpt_flush on current LP (dom0 is running). So VHPT table is not flushed on the LP that destroyed domU is running. The mechanism of domain reboot is to kill current domain and create a new domain with same configuration. Since region id recycle is added last time with domain destroy support, the new created domain will inherit same region id as previous one. Under this case, the stale entries in VHPT table will make new domU halt. Before applying our schedule_tail patch, domU will keep same pta value as idle domain when first created where vhpt walker is disabled. Because we use bvt as default scheduler, context switch never happens as long as domU is runnable. That means domU will have vhpt DISABLED in whole life cycle. So even vhpt on that LP is not flushed, domU still runs correctly. So we need to send IPI to target LP to flush right vhpt table. Especially, based on our previous patch for schedule_tail, domU can get performance gain by enabling vhpt walker. Best Regards - Kevin Xiantao fix_reboot_bug_with_vhpt_enable.patch Description: fix_reboot_bug_with_vhpt_enable.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Scp big file to xen0 will fail
Hi all, Currently, scp a big size file (IG or bigger) to xen0 will fail in midway without VTi or xenU exist. The phenomena is as below. 1.Boot machine to xen0 2.start some applications such as xend, vncserver and so on. 3.scp a big size file from remote machine to xen0, and will see scp status to be stalled and xen0 is slower and slower. At last, the whole system hangs. My analysis about it: When it happens, we can see the most of cpu time was occupied by pdflush in xen0. But pdflush thread was only scheduled when system has small amount of free buffer memory and it will flush buffer pages to disk. This operation will do flush_tlb_all, and as to ptc.e of flush_tlb_all needs xen to emulate. The emulation of xen has very low performance. It will flush all vhpt entries and all tlbs of LP. Then, the sshd will get less chance to be scheduled. From client view, network broken and xen0 hangs. So the root cause should be low efficiency of ptc_e emulation . In order to prove this thought, I have done several experiments on it. 1. Extend xen0's memory to 640M from 512M, this will reduce times of pdflush operation heavily. So the ptc.e emulation also decreases accordingly. 2. Disable vhpt of xen0, if so, xen don't need to do flush vhpt in ptc.e emulation. The either of two methods can resolve the issue. But they are just for workaround not the final solution. Anyway, in order to fix the bug, we should find better solution to improve performance of ptc.e emulation . Please give comments :) My machine status: Platform : tiger4 OS: rehel4-u2 Memory :512M Please give comments. Thanks -Xiantao Zhang ___ 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 seems broken.
Hi Tristan, I am using CSet9675 now. It should be OK with me :) Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tristan Gingold Sent: 2006年4月12日 19:45 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] xen-ia64-unstable.hg seems broken. Hi, the current changeset (9675) seems broken. Confirmation ? 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
[Xen-ia64-devel] [PATCH] Fix the total memory info with xm info command
This small patch intends to provide correct total memory info for control panel and fixed hardcode for that. The total memory info doesn't include the memory FW used. Signed-off-by : Zhang Xiantao [EMAIL PROTECTED] Thanks -Xiantao total_memory.patch Description: total_memory.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]Fix vm_summary info in VTi domain
This patch fixed vm_summary info and provide correct max_itr_entry, max_dtr_entry,impl_va_msb, rid_size and so on for VTi domain. Signed-off-by: Zhang xiantao [EMAIL PROTECTED] Thanks -Xiantao vm_info.patch Description: vm_info.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] panic - panic domain
This patch uses panic domain instead of panic when the panic happening is only related to current domain other than whole system. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] Thanks -Xiantao panic_to_panic_domain.patch Description: panic_to_panic_domain.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Clear rse invalid partition before resuming to VTi guest
This patch intends to provide mechanism for clearing rse invalid partition before rbs switch to guest. To avoid leaking hypervisor bits to guest, it is a must to clear registers which are in invalid partition before leaving hypervisor. Tested by full ltp test and Verified by ITP in some cases. Thanks -Xiantao rse_clear_invalid_when_resume_guest.patch Description: rse_clear_invalid_when_resume_guest.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Allow multiple-time mmap of theprivcmddevice
Hi Alex/ Yamahata, Thanks your help, I can boot VTi up with VP_mode now. When configured Xen0 with 800M and VTi with 256M, VTi seems OK :) Thanks for your detail information. -Xiantao -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年5月17日 11:15 To: Zhang, Xiantao Cc: Isaku Yamahata; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH] Allow multiple-time mmap of theprivcmddevice On Wed, 2006-05-17 at 10:54 +0800, Zhang, Xiantao wrote: Hi Yamahata /Alex, When I configured memory 800M for xen0 and 128M for VTi, I can create VTi to EFi with VP_mode, but it couldn't boot to system. I attached screen picture, and could you give more tips? :) With dom0_mem=800M I can boot a VTi domain w/ default 512MB memory. Maybe your config doesn't work well with 128M? Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Allow multiple-time mmap of the privcmddevice
Hi Yamahata, Although I have booted up VTi with VP mode, seems that it is not stable yet. After creating for about 2 hours, it will panic without any workload on it. Did you see the same issue?. Once capture the log, I will send it to you. :) Thanks -Xiantao -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年5月17日 11:19 To: Zhang, Xiantao Cc: Alex Williamson; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Allow multiple-time mmap of the privcmddevice Does increasing memory for VTi from 128M to 256M help? (You may need to increase dom0 memory. I'm not sure.) On Wed, May 17, 2006 at 10:54:43AM +0800, Zhang, Xiantao wrote: Hi Yamahata /Alex, When I configured memory 800M for xen0 and 128M for VTi, I can create VTi to EFi with VP_mode, but it couldn't boot to system. I attached screen picture, and could you give more tips? :) Thanks a lot. -Xiantao -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年5月17日 9:48 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Allow multiple-time mmap of the privcmddevice Thank you for the log. The oom-killer of dom0 was triggered. Alex also reporeted it. Please increase dom0 memory and decrease vti domain memory as a work around for now. When I tested, I used 512MB(default) for dom0 and 128MB for vti domU. The root cause is the current implementation of foregin domain page mapping wastes dom0 memory to allocate pseudo physical address. (xen_ia64_privcmd_entry_mmap() in linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c) I will fix this waste of dom0 memory by foreign domain page mapping. On Wed, May 17, 2006 at 08:48:00AM +0800, Zhang, Xiantao wrote: Hi Yamahata, I attached the log, and I have tried two times but all failed with same phenomenon. Thanks -Xiantao -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年5月16日 21:24 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Allow multiple-time mmap of the privcmddevice On Tue, May 16, 2006 at 07:40:45PM +0800, Zhang, Xiantao wrote: With this patch and Alex's network.diff on tip, I couldn't create VTi domain yet, and it will result in xen to panic. Does it need other patches to work? No. Can I see panic log? -- yamahata ___ 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 -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Fix xm pause/unpause bug
This small patch intends to fix domain pause/unpause bug. Current xm pause operation will do sync_vcpu_execstate to sync vcpu status, but it saves dom0's fpu and other registers to VTi domain or domainU due to xm pause from control panel. Because sync_vcpu_execstate was called after vcpu_sleep which has saved all necessary status when schedule out ,in addition, currently no lazy states need to be saved in IPF side, so sync_vcpu_execstate needs to do nothing now. Thanks -Xiantao xm_pause.patch Description: xm_pause.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Allow multiple-time mmap of the privcmddevice
OK, I see. thanks -Xiantao -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年5月17日 15:36 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Allow multiple-time mmap of the privcmddevice On Wed, May 17, 2006 at 02:20:36PM +0800, Zhang, Xiantao wrote: Although I have booted up VTi with VP mode, seems that it is not stable yet. After creating for about 2 hours, it will panic without any workload on it. Did you see the same issue?. Once capture the log, I will send it to you. :) Thanks Hi Xiantao. Actually I tested only vti-domain boot only so that I haven't met such issues. I won't be surprised at stability issues though. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] No such file or directory: '/proc/xen/balloon'
Hi Dietmar, Seems your machine has no enough memory for creating the domain. Maybe you can make a try to decrease xenU's memory. Before creating xenU, you can use xm info to see system's free memory. Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dietmar Hahn Sent: 2006年5月19日 15:55 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] No such file or directory: '/proc/xen/balloon' Hi, I cloned the http://xenbits.xensource.com/ext/xen-ia64-unstable.hg tree and built and installed a fresh xen on a hp zx6000 dom0 is running fine. But if I try to start domU I get always the error: # xm create -c linux1 Using config file /etc/xen/linux1. Error: [Errno 2] No such file or directory: '/proc/xen/balloon' Because the config flag CONFIG_XEN_IA64_DOM0_VP is off the ballon driver is not built and therewith there is no /proc/xen/ballon. Do I miss some configuration flags or have I installed wrong tools? Thanks for your help! Dietmar. ___ 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: [Fedora-xen] fedora-xen-ia64 first pass
Hi, Aron We have tried to boot xen with your tip, but found the configuration for domain0 opens dom0_VP mode, however, the dom0_VP option of xen was closed by default. Maybe this is the main reason why xen dies at booting xen0. Correct? If they don't match, it is impossible to boot up. Due to not familiar with rpmbuild scripts, so we have to modify it manually to try. Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aron Griffis Sent: 2006年5月21日 3:35 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: [Fedora-xen] fedora-xen-ia64 first pass Hello, I've made a first pass at modifying the Fedora Rawhide xen and kernel rpms to support ia64. There is still a lot of work to do before this would be suitable for inclusion in Fedora, but hopefully this represents a proof-of-concept that can be improved to that point. If you'd like to browse or contribute, the bits are available as mercurial repositories at: http://free.linux.hp.com/~agriffis/ There are 5 repositories presently: fedora-xen-rpm Tracks xen.src.rpm from rawhide. fedora-xen-ia64 Pulls from fedora-xen-rpm, contains (trivial) modifications for ia64 fedora-kernel-rpm Tracks kernel.src.rpm from rawhide. fedora-kernel-ia64 Pulls from fedora-kernel-rpm, contains modifications for ia64 xen-ia64-unstable-2.6.17Forward port of xen-ia64-unstable sparse tree from 2.6.16.13 to 2.6.17, generates linux-2.6-xen.patch for fedora-kernel-ia64 Here is my non-comprehensive list of notes/issues for fedora-kernel-ia64: 1. Upstream xen is presently based on 2.6.16.13. Fedora kernel is (or was yesterday) based on 2.6.17-rc4-git5. To port xen forward, the most maintainable method seems to be to do the port in the context of a xen-ia64-unstable mercurial clone (xen-ia64-unstable-2.6.17 above). Using this method makes it relatively easy to: (a) port forward to a new kernel at any time using the sparse-merge script (b) pull new changes from upstream xen and avoid most manual merging (c) extract a patch at any time that represents the forward-port of xen to a new kernel (d) generate a patch at any time that adds xen support to the fedora kernel (linux-2.6-xen.patch generated with make mkpatches) The only caveat here is that I probably didn't do the forward port perfectly. In particular I know I bungled the TPM stuff because there are lots of changes going into kernel.org and xen simultaneously. Additionally I didn't pay a lot of attention to other architectures for the moment. Hopefully 2.6.17 will pop any day now, then xen upstream will move to it, and we won't have to carry the forward port in the Fedora patch. If by some chance this doesn't happen, then my forward porting work will need to be revisited. 2. This first pass was created using the xen-ia64-unstable repo instead of the xen-unstable repo. This is because xen-unstable is broken recently on ia64. When the two have been resynced upstream, and xen-unstable works on ia64, we should move this prototype to using xen-unstable (which is what the current Fedora Xen patch is based on). 3. The bare metal config is built for Generic. The xen0 and xenU configs are built for DIG-Compliant. It seems that the kernel won't build for Generic with CONFIG_XEN enabled. Using DIG-compliant for the xen kernels is probably okay for now, but it would be good to get Generic building. 4. After applying patch700 (linux-2.6-xen.patch), the spec file executes xen-mkbuildtree-pre if it exists for the architecture. In effect, this is applying an ia64-specific patch, even though it looks more generic in the spec. The special modifications being made by xen-mkbuildtree-pre need to be folded into linux-2.6-xen.patch to prevent architecture-specific maintenance headaches in the stack of Fedora kernel patches. 5. My forward port broke the exec-shield patch application. Juan has this resolved in his version, but that's based on an older xen-unstable changeset. I commented out patch810-812 for the moment. 6. The xen patch is missing some function prototypes. (I believe this is a problem in xen upstream not something introduced by my port.) The Fedora kernel build normally turns on -Werror-implicit-function-declaration in patch1018 (linux-2.6-debug-Wundef.patch). I commented out this patch for the moment. 7. The hypervisor doesn't build on ia64 with debug=y verbose=y crash_debug=y. For the moment it builds with default flags on ia64 instead. 8.
[Xen-ia64-devel] About oom-killer bug
Hi, Yamahata We have tried the latest #CSet, and found oom-killer bug is there now. Do you have any update on this? Could you share the final solution for it? In addition, another bug was found by Intel QA team after dom0_VP open. We could't use tty0, tty1 ,ttyx and so on to login system and these terminals has nothing output, only one cursor is blinking in screen after xen0 boot up. Do you have any idea about it? Thanks -Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] [RESEND]clean up vti code
Hi Alex, I have checked this patch on tip(10146), and didn't met the issue with rhel4-u2 and urhel4-u3 image. Maybe the issue you mentioned is not caused by Anthony's patch :) Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006年5月24日 5:35 To: Xu, Anthony Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH] [RESEND]clean up vti code On Fri, 2006-05-19 at 16:48 +0800, Xu, Anthony wrote: fixed vmx_ivt.S was only the first example, there are still intermixed spaces and tabs throughout this patch. Please update the rest as well. Also, a RHEL4U3 guest running in domVTi fails to boot with this patch. There seems to be something wrong with the block device code. Screen shot attached. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Add ptc.l emulation for 2.6.17 xenlinux to fix federon-xen-ia64 boot
This patch adds support for ptc.l emulation. In 2.6.16 kernel flush_tlb_range will call global_tlb_purge directly, so ptc.l shouldn't be used when CONFIG_SMP enable. But in order to enhance performance (maybe), 2.6.17 kernel in smp environment will do mm check first. If mm is current-active_mm and the mm (corresponding process) just runs on the local processor, kernel only needs to do ptc.l at local processor instead of global purge. So ptc.l emulation is necessary for 2.6.17 kernel. Hi Aron, With this patch, federon-xen-ia64 with rhel4-u2 can boot to switch to new root. Seems this error is related to FC6 OS, due to lack of FC6 at hand, we couldn't try to boot it on FC6. Anyway, this patch is a must for boot 2.6.17 kernel. In addition, I attached the boot log, anyone can help to try on FC6 with this patch? Thanks -Xiantao panic.log Description: panic.log ptc_l_support.patch Description: ptc_l_support.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] XEN on machines with EFI
Rodrigo, From your log, it should be caused by incorrect elilo. The current elilo for xen is a modified version, and it can support vmm option. You can get it from xen source @ ./xen/arch/ia64/tools/xelilo/xlilo.efi. Pls have a try . Thanks -Xiantao From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rodrigo Lord Sent: 2006年5月26日 20:40 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] XEN on machines with EFI Hello! I installed the xen-ia64 version on an Itanium2. I`m using Debian Sarge 3.1! I configured the elilo.conf normally, but when I reboot... not shows the option XEN on my elilo! How do I boot the xen using EFI? Anything different? It hangs when try to load the line vmm=/boot/xen.gz: Unkown option vmm 7 0 0x6B 0x0018 unexpected trap 7 0 0x66 0x0018 trap taken,number in ext PE 7 0 0x3C 0x5400 trap taken,offset in ext PE My elilo.conf: install=/usr/lib/elilo/elilo.efi boot=/dev/sda1 delay=20 default=linux image=/boot/vmlinuz label=linux root=/dev/sda2 initrd=/boot/initrd.img read-only image=/boot/xenlinuz vmm=/boot/xen.gz label=xen root=/dev/sda2 initrd=/boot/initrd.xen read-only append=sync_console dom0_mem=768M max_addr=64G -- nomca root=/dev/sda2 xencons=ttyS8 console=ttyS8 Thanks! ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]set isr before injecting fault to guest.
This patch intends to fix isr setting before injecting fault to it. With this small fix, CPU2000 in VTi can pass now. Thanks -Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]set isr before injecting fault to guest.
Sorry for forgetting the attachment. Patch attached. Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2006年5月31日 10:35 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH]set isr before injecting fault to guest. This patch intends to fix isr setting before injecting fault to it. With this small fix, CPU2000 in VTi can pass now. Thanks -Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel set_isr.patch Description: set_isr.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug.
After enabling dom0_vp mode, we lost domain0's VGA console, and we have to connect it through network or serial console. The reason is that VGA frame buffer(0xa-0xc) was set to conventional memory not IO in dom0's p2m table. Attached patch fixes it. Thanks -Xiantao fix_dom0_vga_console.patch Description: fix_dom0_vga_console.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug.
Hi Alex, We are using tiger4 platform. I didn't find md about space: 0xa-0xc in efi memmap, maybe it was assumed EFI_MEMORY_MAPPED_IO in native OS. But dom_fw_init shouldn't neglect it to set IO space according to MDs efi provides. Seems your platform has VGA console. So this patch can enable VGA console on all platforms explicitly, maybe as you said this step is better to do in dom_fw_init :) Thanks -Xiantao -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年5月31日 23:32 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug. On Wed, 2006-05-31 at 20:30 +0800, Zhang, Xiantao wrote: After enabling dom0_vp mode, we lost domain0's VGA console, and we have to connect it through network or serial console. The reason is that VGA frame buffer(0xa-0xc) was set to conventional memory not IO in dom0's p2m table. Attached patch fixes it. Hi Xiantao, What about systems that don't have VGA? What memory type does your system report in the EFI MDT for address 0xA? I would expect EFI_MEMORY_MAPPED_IO, but if it's something else, it probably needs to be assigned a passthrough in dom_fw_init(). Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug.
Hi Alex, The updated patch should be happy for all platforms. If EFI doesn't provide md for range(0xa-0xc) to OS. It maybe a hole or occupied by legacy vga. Therefore, I used the efi_mmio function to check it. If these pages was not mapped yet and efi_mmio return true, we can map them as MMIO safely. BTW, this patch based on Yamahata's check memory descriptor overlap patch. Please give comments. :) Thanks -Xiantao -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年6月1日 10:11 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug. On Thu, 2006-06-01 at 09:45 +0800, Zhang, Xiantao wrote: Hi Alex, We are using tiger4 platform. I didn't find md about space: 0xa-0xc in efi memmap, maybe it was assumed EFI_MEMORY_MAPPED_IO in native OS. But dom_fw_init shouldn't neglect it to set IO space according to MDs efi provides. Seems your platform has VGA console. So this patch can enable VGA console on all platforms explicitly, maybe as you said this step is better to do in dom_fw_init :) Hi Xiantao, One of my test systems has VGA, the other does not. We cannot assume VGA in the system. If the MDT on the tiger4 doesn't describe that range, then we probably need to at least revert to the test the Linux kernel uses and test whether that range has a WB memory attribute before assuming it's VGA. Also, try not to double map the range for platforms that do describe this as type EFI_MEMORY_MAPPED_IO. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. xen0_console.patch Description: xen0_console.patch ---BeginMessage--- This patch tries to check MD's overlap and tries not to assign page to non conventional area. Maybe you may want to apply this patch before VGA-related modifications. On Wed, May 31, 2006 at 08:10:42PM -0600, Alex Williamson wrote: On Thu, 2006-06-01 at 09:45 +0800, Zhang, Xiantao wrote: Hi Alex, We are using tiger4 platform. I didn't find md about space: 0xa-0xc in efi memmap, maybe it was assumed EFI_MEMORY_MAPPED_IO in native OS. But dom_fw_init shouldn't neglect it to set IO space according to MDs efi provides. Seems your platform has VGA console. So this patch can enable VGA console on all platforms explicitly, maybe as you said this step is better to do in dom_fw_init :) Hi Xiantao, One of my test systems has VGA, the other does not. We cannot assume VGA in the system. If the MDT on the tiger4 doesn't describe that range, then we probably need to at least revert to the test the Linux kernel uses and test whether that range has a WB memory attribute before assuming it's VGA. Also, try not to double map the range for platforms that do describe this as type EFI_MEMORY_MAPPED_IO. 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 -- yamahata # HG changeset patch # User [EMAIL PROTECTED] # Node ID e3e02e227b3e8d97537c38d5cdba9959bdd05d6a # Parent f6774d15d763fead75e6320e63fa1f14fabab26a check memory descriptor over lap in dom_fw_init() and assign page to dom0 precisely. PATCHNAME: assign_page_to_dom0_precisely Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff -r f6774d15d763 -r e3e02e227b3e xen/arch/ia64/xen/dom_fw.c --- a/xen/arch/ia64/xen/dom_fw.cThu Jun 01 11:39:04 2006 +0900 +++ b/xen/arch/ia64/xen/dom_fw.cThu Jun 01 11:39:06 2006 +0900 @@ -1017,11 +1017,16 @@ dom_fw_init (struct domain *d, const cha /* simulate 1MB free memory at physical address zero */ MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,0*MB,1*MB, 0);//XXX +#else +int num_mds; +int j; #endif /* hypercall patches live here, masquerade as reserved PAL memory */ MAKE_MD(EFI_PAL_CODE,EFI_MEMORY_WB|EFI_MEMORY_RUNTIME,HYPERCALL_START,HYPERCALL_END, 0); + + +#ifndef CONFIG_XEN_IA64_DOM0_VP MAKE_MD(EFI_CONVENTIONAL_MEMORY,EFI_MEMORY_WB,HYPERCALL_END,maxmem-IA64_GRANULE_SIZE, 0);//XXX make sure this doesn't overlap on i/o, runtime area. -#ifndef CONFIG_XEN_IA64_DOM0_VP /* hack */ MAKE_MD(EFI_CONVENTIONAL_MEMORY,EFI_MEMORY_WB,last_start,last_end,1); #endif @@ -1054,6 +1059,52 @@ dom_fw_init (struct domain *d, const cha dom_fw_dom0_passthrough, arg); } else MAKE_MD(EFI_RESERVED_TYPE,0,0,0,0); + +#ifdef CONFIG_XEN_IA64_DOM0_VP +// simple +// MAKE_MD(EFI_CONVENTIONAL_MEMORY, EFI_MEMORY_WB, +// HYPERCALL_END, maxmem, 0); +// is not good. Check overlap. +sort(efi_memmap, i, sizeof(efi_memory_desc_t), efi_mdt_cmp
RE: [Xen-ia64-devel] Re: [Xen-users] XEN on machines with EFI
Hi Rodrigo, Akio is right. Of course, you can make a try with old initrd.img . Maybe it is OK for your system. Thanks -Xiantao -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006年6月2日 9:46 To: Rodrigo Lord; Zhang, Xiantao; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] Re: [Xen-users] XEN on machines with EFI Hi, Rodrigo # mkinitrd -o /boot/efi/efi/debian/initrd-2.6.16.13-xen0.img 2.6.16.13-xen0 find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory . Did you do the below? 5. make initrd for Dom0/DomU # cd linux-2.6.16.13-xen/ # make modules_install --this one # mkinitrd -f /boot/efi/efi/redhat/initrd-2.6.16.13-xen.img 2.6.16. 13-xen --builtin mptbase --builtin mptscsih # cd .. And you may use --builtin option. Whenever I mkinitrd, I do the below. mkinitrd -f /boot/efi/efi/xen/initrd-2.6.16.13-xen.img 2.6.16.13-xen -- builtin mptbase --builtin mptscsih Best Regards, Akio Takebe Hello! Yes, I understood! I think that the EFI isn`t more my problem! :) I`m with problems to create my initrd! # mkinitrd -o /boot/efi/efi/debian/initrd-2.6.16.13-xen0.img 2.6.16.13-xen0 find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory . . . Any help? Thanks! ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Handle VTi's fp fault and trap inhypervisor instead of injecting to guest.
Hi Alex, Please drop this patch. Thanks Best Regards -Xiantao OTC,Intel corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2006年6月2日 16:37 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH] Handle VTi's fp fault and trap inhypervisor instead of injecting to guest. This patch intends to handle VTi's fp fault and trap in hypervisor instead of injecting to guest. Thanks -Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Resend [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug.
Just resend. Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2006年6月1日 16:29 To: Alex Williamson Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug. Hi Alex, The updated patch should be happy for all platforms. If EFI doesn't provide md for range(0xa-0xc) to OS. It maybe a hole or occupied by legacy vga. Therefore, I used the efi_mmio function to check it. If these pages was not mapped yet and efi_mmio return true, we can map them as MMIO safely. BTW, this patch based on Yamahata's check memory descriptor overlap patch. Please give comments. :) Thanks -Xiantao -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年6月1日 10:11 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug. On Thu, 2006-06-01 at 09:45 +0800, Zhang, Xiantao wrote: Hi Alex, We are using tiger4 platform. I didn't find md about space: 0xa-0xc in efi memmap, maybe it was assumed EFI_MEMORY_MAPPED_IO in native OS. But dom_fw_init shouldn't neglect it to set IO space according to MDs efi provides. Seems your platform has VGA console. So this patch can enable VGA console on all platforms explicitly, maybe as you said this step is better to do in dom_fw_init :) Hi Xiantao, One of my test systems has VGA, the other does not. We cannot assume VGA in the system. If the MDT on the tiger4 doesn't describe that range, then we probably need to at least revert to the test the Linux kernel uses and test whether that range has a WB memory attribute before assuming it's VGA. Also, try not to double map the range for platforms that do describe this as type EFI_MEMORY_MAPPED_IO. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. xen0_console.patch Description: xen0_console.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Enable xen0 smp when machine only has2 LPs
Hi Alex, I couldn't reproduce your troubles here with this change. Could you check with xm vcpu-list to see the time of vcpus? I also found xenU state -, but I think it should be normal, because LPs were occupied by xen0 at that time. Only if time of vcpus is increasing, domU should be alive. I am also confused that CONFIG_NR_CPUS was set to 16 in xenU's configuration file(linux-defconfig_xenU_ia64), Why not come across those troubles before? Maybe we should come out a better solution for this issue. Anyway it is a must to set CONFIG_NR_CPUS to 4 for xen0 and XenU when LPs 4. Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年6月21日 7:41 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH]Enable xen0 smp when machine only has2 LPs On Tue, 2006-06-20 at 18:02 +0800, Zhang, Xiantao wrote: This patch intends to enable xen0's smp when machine only has 2 LPs. Thanks Best Regards Xiantao, For such a simply change, this patch caused me a lot of trouble. When I repeatedly reboot domU, I can get it into a state reported as -- by xm list. The domU console appears hung. I can always get it out of this state by running xenctx on the domain. At that point the console wakes up again and I get a software watchdog oops in the domU. The backtrace in the oops is a standard cpu_idle kind of patch. My HVM capable systems sometimes even failed to boot dom0 when I applied 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
RE: [Xen-ia64-devel] [PATCH]Enable xen0 smp when machine only has2LPs
Very strange! Seems it is related to different platforms. Maybe potential bugs invoked these troubles in smp environment. :) I will retry to produce them and wish to get it. Thanks. -Xiantao OTC,Intel Corporation -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年6月21日 11:11 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH]Enable xen0 smp when machine only has2LPs On Wed, 2006-06-21 at 10:04 +0800, Zhang, Xiantao wrote: Hi Alex, I couldn't reproduce your troubles here with this change. Could you check with xm vcpu-list to see the time of vcpus? I also found xenU state -, but I think it should be normal, because LPs were occupied by xen0 at that time. Only if time of vcpus is increasing, domU should be alive. Hi Xiantao, The vcpu time on my domU was not increasing. The watchdog oops in the domU when kicking it with xenctx also indicates that domU was getting no time. FWIW, I saw this on a zx6000, madison system (2-way box). I was booting a UP dom0 w/ 2GB of memory, and a UP domU w/ 1GB of memory. DomU is configured with 1 vnif, and only booted to single user mode. I usually saw the domU hang within about 5 reboots. I am also confused that CONFIG_NR_CPUS was set to 16 in xenU's configuration file(linux-defconfig_xenU_ia64), Why not come across those troubles before? Nobody tests the -xenU kernel on a regular basis anymore. I typically only test the -xen kernel. Maybe we should come out a better solution for this issue. Anyway it is a must to set CONFIG_NR_CPUS to 4 for xen0 and XenU when LPs 4. I agree, and I can't explain why such a seemingly simple change triggered this problem. 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] [PATCH]A typo fix
Fix a typo. Thanks Best Regards -Xiantao OTC,Intel Corporation typo_fix.diff Description: typo_fix.diff ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Enable FW accleration for VTi
This patch intends to turn on FW acceleration for VTi. Thanks Best Regards -Xiantao OTC,Intel Corporation fw_acc.patch Description: fw_acc.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating a VTImake xen0 hang
Hi Alex, Seems this issue was caused by Cset 10688. In vcpu_itr_d, the current logic purges vhpt with cpu_flush_vhpt_range but it is very heavy to xen0. When creating VTi domain @ early stage, IO operation is very excessive, so qemu was scheduled out and in very frequently and this logic was executed every time. In addition, cpu_flush_vhpt_range using identity map to purge vhpt may cause more tlb miss due to no TR map. If remove vcpu_flush_tlb_vhpt_range logic although it definitely needed, seems VTi becomes healthy. Maybe potential bugs exist there.:) Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年7月11日 11:28 To: Zhang, Jingke Cc: xen-ia64-devel@lists.xensource.com; Zhang, Xiantao; [EMAIL PROTECTED] Subject: RE: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating a VTImake xen0 hang On Tue, 2006-07-11 at 10:13 +0800, Zhang, Jingke wrote: Just add comments to this problem: With Cset 10684, VTI domain creating does well. Cset 10685 emulate PAL_HALT_LIGHT on domU seems to play a significant part of this. On cset 10690 it takes ~30 seconds to get to an EFI shell prompt for a VTI domain. If I 'hg export 10685 | patch -p1 -R' (ie. back out cset 10685), VTI domains start in ~5 seconds. 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] [IPF-ia64] with Cset 10690, creating a VTImake xen0 hang
Hi Alex, Our QA team reported that xen0 would hang after creating VTi domain @CSet 10688-10694. Should we reverse the logic of vcpu_itr_d first ? Maybe we can find out the real bottleneck later.:) Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Atsushi SAKAI [mailto:[EMAIL PROTECTED] Sent: 2006年7月11日 21:46 To: Alex Williamson; Zhang, Xiantao Cc: Isaku Yamahata; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating a VTImake xen0 hang Hi, Alex Sorry for late. I found your problem(boot time difference w/ PAL_HALT_LIGHT emulation patch) occurred in SMP(credit). But, it does not occurred in UP, SMP(bvt) and SMP(credit w/ affinity). I think the emulation of pal_halt_light for domU does not good work for DomVTI boot up under credit scheduling w/o affinity. And consider the Xiantao survey, qemu make heavy I/O operations at the boot up. Consider the above two conditions, I think credit scheduler algorithm does not consider the block state.(caused by pal_halt_light emulation) So I want to switch off the vcpu migration at heavy load I planned as follows. 1)In the short term, I want to avoid this problem by HALT the PAL_HALT_LIGHT emulation while DomVTI boot up. or Lock VCPUs migrations while DomVTI boot up. (when Credit scheduler runs) 2)In the long term, I will make a patch to avoid this problem. (Consider the heavy io w/ vcpu migration) N.B. I checked under CS:10559.(original patch made) Thanks, Atsushi SAKAI On Tue, 2006-07-11 at 19:42 +0800, Zhang, Xiantao wrote: Hi Alex, Seems this issue was caused by Cset 10688. In vcpu_itr_d, the current logic purges vhpt with cpu_flush_vhpt_range but it is very heavy to xen0. When creating VTi domain @ early stage, IO operation is very excessive, so qemu was scheduled out and in very frequently and this logic was executed every time. In addition, cpu_flush_vhpt_range using identity map to purge vhpt may cause more tlb miss due to no TR map. If remove vcpu_flush_tlb_vhpt_range logic although it definitely needed, seems VTi becomes healthy. Maybe potential bugs exist there.:) Thanks for investigating Xiantao. Isaku, any thoughts on how to regain VTI performance? 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] [PATCH][XEND]Fix memory allocation for VTi domain with new Qemu on xen-unstagle.hg
Due to IA64 balloon driver not ready and it depends on max memory value to allocate its memory. So this fix is necessary now. Thanks Best Regards -Xiantao OTC,Intel Corporation fix_ia64_mem_alloc.patch Description: fix_ia64_mem_alloc.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH][QEMU] Add IA64-specific code for new qemu.
This patch adds the ia64-specific code for new Qemu . In addition, some ia64 patches aren't checked into xen-unstable.hg, so I reversed the related logic temporarily. Once sync with xen-ia64-unstable.hg, the logic will regain automatically. Thanks Best Regards -Xiantao OTC,Intel Corporation ia64_specific_code_for_qemu.patch Description: ia64_specific_code_for_qemu.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH][QEMU] Add IA64-specific code for new qemu.
Akio,
Thank you for pointing out this issue. Maybe I sent out the older one
incorrectly.:( Thanks again.
-Xiantao
OTC,Intel Corporation
-Original Message-
From: Akio Takebe [mailto:[EMAIL PROTECTED]
Sent: 2006年7月26日 19:24
To: Zhang, Xiantao; [EMAIL PROTECTED]
Cc: xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] [PATCH][QEMU] Add IA64-specific code for new
qemu.
Hi, Xiantao
Is the following testandset redefine?
diff -r bbabdebc54ad tools/ioemu/exec-all.h
--- a/tools/ioemu/exec-all.h Wed Jul 19 21:13:36 2006 +0100
+++ b/tools/ioemu/exec-all.h Tue Jul 25 09:30:05 2006 +0800
@@ -391,6 +391,15 @@ static inline int testandset (int *p)
}
#endif
+#ifdef __ia64__
+#include ia64_intrinsic.h
+static inline int testandset (int *p)
+{
+uint32_t o = 0, n = 1;
+return (int)cmpxchg_acq(p, o, n);
+}
+#endif
+
#ifdef __s390__
static inline int testandset (int *p)
{
Best Regards,
Akio Takebe
This patch adds the ia64-specific code for new Qemu .
In addition, some ia64 patches aren't checked into xen-unstable.hg, so I
reversed the related logic temporarily. Once sync with
xen-ia64-unstable.hg, the logic will regain automatically.
Thanks Best Regards
-Xiantao
OTC,Intel Corporation
---text/plain---
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Add lost logic for VGA initialization
Hi Alex, That's very strange. We tried to boot VTi on CSet(10784) with VGA initialization fix and didn't met your issue. I am trying to reproduce your issue here. Hope to find it:) Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006年7月27日 3:20 To: Zhang, Xiantao Cc: [EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-devel] [PATCH] Add lost logic for VGA initialization On Wed, 2006-07-26 at 13:38 +0800, Zhang, Xiantao wrote: Hi Alex, With this fix and previous patches, we can boot VTi successfully with new Qemu on xen-ia64-unstable.hg 's tip(10784). Should we make xen-unstable.hg sync with xen-ia64-unstable.hg happen next step? Yes, I sync'd with xen-unstable.hg. There's still a build issue with the qemu files, and I've sent a patch to Christian that fixes it: http://lists.xensource.com/archives/html/xen-devel/2006-07/msg00861.html There's still some debugging left to do on xen-ia64 though. When starting a VTI domain on the xen-ia64-unstable.hg tip (cset 10809) the domain sits in the blocked state and doesn't accumulate cpu time. If I apply the attached patch (reinstating changes from xen-ia64 cset 10570), I get a little farther and can connect to the VNC session for the domain, but we never get to EFI. Thanks, Alex Signed-off-by: Alex Williamson [EMAIL PROTECTED] --- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Add lost logic for VGA initialization
Hi, Christian Thank you for your comments. But I check the patch on tip. Seems the following line not in upstream. I don't know why this part was lost when check-in. diff -r 254c090854de tools/ioemu/hw/vga.c --- a/tools/ioemu/hw/vga.c Wed Jul 26 15:59:36 2006 -0600 +++ b/tools/ioemu/hw/vga.c Thu Jul 27 09:27:03 2006 +0800 @@ -1953,6 +1953,7 @@ void vga_common_init(VGAState *s, Displa vga_screen_dump, s); /* XXX: currently needed for display */ vga_state = s; +vga_bios_init(s); } Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Christian Limpach [mailto:[EMAIL PROTECTED] Sent: 2006年7月26日 22:23 To: Zhang, Xiantao Cc: [EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] Add lost logic for VGA initialization On 7/26/06, Zhang, Xiantao [EMAIL PROTECTED] wrote: This patch adds lost logic for vga initialization. It was lost after changing to new Qemu. Signed-off-by : Kevin Tian [EMAIL PROTECTED] Signed-off-by : Zhang Xiantao [EMAIL PROTECTED] I've applied this -- it would be nice if you could cleanup the code some more to use arrays to initialize s-sr[], s-gr[], s-ar[] and s-cr[]. Thanks! christian ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Add lost logic for VGA initialization
Hi Alex, I found the reason why VTi couldn't get into EFi. Seems the patch which adds VGA bios initialization lost one part @check-in. With this fix and your attached patch. VTi should be healthy except network issue. diff -r 254c090854de tools/ioemu/hw/vga.c --- a/tools/ioemu/hw/vga.c Wed Jul 26 15:59:36 2006 -0600 +++ b/tools/ioemu/hw/vga.c Thu Jul 27 09:27:03 2006 +0800 @@ -1953,6 +1953,7 @@ void vga_common_init(VGAState *s, Displa vga_screen_dump, s); /* XXX: currently needed for display */ vga_state = s; +vga_bios_init(s); } Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006年7月27日 3:20 To: Zhang, Xiantao Cc: [EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-devel] [PATCH] Add lost logic for VGA initialization On Wed, 2006-07-26 at 13:38 +0800, Zhang, Xiantao wrote: Hi Alex, With this fix and previous patches, we can boot VTi successfully with new Qemu on xen-ia64-unstable.hg 's tip(10784). Should we make xen-unstable.hg sync with xen-ia64-unstable.hg happen next step? Yes, I sync'd with xen-unstable.hg. There's still a build issue with the qemu files, and I've sent a patch to Christian that fixes it: http://lists.xensource.com/archives/html/xen-devel/2006-07/msg00861.html There's still some debugging left to do on xen-ia64 though. When starting a VTI domain on the xen-ia64-unstable.hg tip (cset 10809) the domain sits in the blocked state and doesn't accumulate cpu time. If I apply the attached patch (reinstating changes from xen-ia64 cset 10570), I get a little farther and can connect to the VNC session for the domain, but we never get to EFI. Thanks, Alex Signed-off-by: Alex Williamson [EMAIL PROTECTED] --- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Fedora-xen] [PATCH 0 of 5] fix linux-2.6-xen-fedora on ia64
Hi Aron, Could you share me the current status for fedora-xen-ia64? Through your mails, I see we should focus our efforts on linux-2.6-xen-fedora. But when I applied the patch 199684 on it, conflicts occurs. Do you have any suggestion for contributing to Fedora ? Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aron Griffis Sent: 2006年7月27日 12:11 To: Juan Quintela Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright; [EMAIL PROTECTED]; Alex Williamson; xen-ia64-devel@lists.xensource.com Subject: [Fedora-xen] [PATCH 0 of 5] fix linux-2.6-xen-fedora on ia64 Hi Juan, These patches are the result of Akio, Prarit, Alex and me working on fixing the ia64 build of your tree. At this point the bare-metal Linux kernel builds and boots. The xen kernel builds but doesn't complete booting. Nonetheless, since these patches seem to take us most of the way there, we'd like to request them to be applied to your tree. Thanks, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Remove unused contig mem flag for VTi
This patch intends to remove the confusing flag ARCH_VMX_CONTIG_MEM for VTi. It was used for indicating that VTi needs contiguous memory. Currently, it seems useless. In addition, add the flag ARCH_VMX_DOMAIN to ensure VMX_DOMAIN check correctly with all vcpus. Thanks Best Regards -Xiantao OTC,Intel Corporation remove_contig_mem_flag.patch Description: remove_contig_mem_flag.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Hi, a question about 32bit OS running at xen-ia64
Hi Tom, Currently, 32 bit OS couldn’t be run on xen-ia64 due to different architectures between IA32 and IA64. 32 bit application should work well in 64 bit guest with BT technology. Anyway, your idea is very good. Maybe somebody will implement it in future. Thanks Best Regards -Xiantao OTC,Intel Corporation From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Sent: 2006年7月27日 16:35 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] Hi,a question about 32bit OS running at xen-ia64 hi,guys. I guess it may seempretty much weird. I am not sure if 32bit OS such as 32bit Red Hat Linux distribution can run at xen-ia64? I really appreciate any suggestion, thanks a million. Tom ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Remove unused contig mem flag for VTi
Hi, Tristan Yes, but current VMX_DOMAIN check based on vcpu, so I think we had better set a flag in arch_vcpu for convenience or change VMX_DOMAIN implementation. Am I right? Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年7月27日 16:54 To: Zhang, Xiantao; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Remove unused contig mem flag for VTi Le Jeudi 27 Juillet 2006 10:15, Zhang, Xiantao a écrit : This patch intends to remove the confusing flag ARCH_VMX_CONTIG_MEM for VTi. It was used for indicating that VTi needs contiguous memory. Currently, it seems useless. In addition, add the flag ARCH_VMX_DOMAIN to ensure VMX_DOMAIN check correctly with all vcpus. The ARCH_VMX_DOMAIN flag is the same as arch.is_vti. I suppose we don't want this double use. One of them must be removed. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] RE: [Fedora-xen] [PATCH 0 of 5] fixlinux-2.6-xen-fedora on ia64
Hi Akio, Thank you for your information. I am using the CSet34705 which should be latest, and do you mean I should apply Aron's patches on it. right? In addition, what's status about it? BTW, Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006年7月27日 16:47 To: Zhang, Xiantao; Aron Griffis; Juan Quintela Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright; [EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] RE: [Fedora-xen] [PATCH 0 of 5] fixlinux-2.6-xen-fedora on ia64 Hi, Xiantao BZ's patch is old. Today 139 cset is added to linux-2.6-xen-fedora tree. So I think we should use Aron's patches. Best Regards, Akio Takebe Hi Aron, Could you share me the current status for fedora-xen-ia64? Through your mails, I see we should focus our efforts on linux-2.6-xen-fedora. But when I applied the patch 199684 on it, conflicts occurs. Do you have any suggestion for contributing to Fedora ? Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aron Griffis Sent: 2006ト・ヤツ27ネユ 12:11 To: Juan Quintela Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright; [EMAIL PROTECTED]; Alex Williamson; xen-ia64-devel@lists.xensource.com Subject: [Fedora-xen] [PATCH 0 of 5] fix linux-2.6-xen-fedora on ia64 Hi Juan, These patches are the result of Akio, Prarit, Alex and me working on fixing the ia64 build of your tree. At this point the bare-metal Linux kernel builds and boots. The xen kernel builds but doesn't complete booting. Nonetheless, since these patches seem to take us most of the way there, we'd like to request them to be applied to your tree. Thanks, Aron ___ 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] RE: [Fedora-xen] [PATCH 0 of 5] fixlinux-2.6-xen-fedora on ia64
Very clear now! Thank you very much.
-Xiantao
OTC,Intel Corporation
-Original Message-
From: Akio Takebe [mailto:[EMAIL PROTECTED]
Sent: 2006年7月27日 17:36
To: Zhang, Xiantao; Aron Griffis; Juan Quintela
Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright;
[EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com; Akio
Takebe
Subject: RE: [Xen-ia64-devel] RE: [Fedora-xen] [PATCH 0 of 5]
fixlinux-2.6-xen-fedora on ia64
Hi, Xiantao
Yes, you are right.
And I think you must use the following patch.
Now I cannot boot by using xen-ia64-unstable
(not linux-2.6-xen-fedora) on FC6.
I'm debuging it.
Then I'll try to boot by using xen-ia64-unstable/xen and linux-2.6-xen-
fedora.
diff -r 61b945565398 drivers/char/tpm/tpm.h
--- a/drivers/char/tpm/tpm.h Wed Jul 26 17:22:38 2006 +0200
+++ b/drivers/char/tpm/tpm.h Wed Aug 02 00:30:00 2006 +0900
@@ -125,7 +125,7 @@ static inline void tpm_write_index(int b
static inline u32 get_chip_buffersize(struct tpm_chip *chip)
{
- return chip-vendor-buffersize;
+ return chip-vendor.buffersize;
}
extern void tpm_get_timeouts(struct tpm_chip *);
Best Regards,
Akio Takebe
Hi Akio,
Thank you for your information. I am using the CSet34705 which should
be
latest, and do you mean I should apply Aron's patches on it. right? In
addition, what's status about it?
BTW,
Thanks Best Regards
-Xiantao
OTC,Intel Corporation
-Original Message-
From: Akio Takebe [mailto:[EMAIL PROTECTED]
Sent: 2006年7月27日 16:47
To: Zhang, Xiantao; Aron Griffis; Juan Quintela
Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright;
[EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] RE: [Fedora-xen] [PATCH 0 of 5]
fixlinux-2.6-xen-fedora on ia64
Hi, Xiantao
BZ's patch is old.
Today 139 cset is added to linux-2.6-xen-fedora tree.
So I think we should use Aron's patches.
Best Regards,
Akio Takebe
Hi Aron,
Could you share me the current status for fedora-xen-ia64? Through your
mails, I see we should focus our efforts on linux-2.6-xen-fedora. But when
I applied the patch 199684 on it, conflicts occurs. Do you have any
suggestion for contributing to Fedora ?
Thanks Best Regards
-Xiantao
OTC,Intel Corporation
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Aron Griffis
Sent: 2006ト・ヤツ27ネユ 12:11
To: Juan Quintela
Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright;
[EMAIL PROTECTED]; Alex Williamson;
xen-ia64-devel@lists.xensource.com
Subject: [Fedora-xen] [PATCH 0 of 5] fix linux-2.6-xen-fedora on ia64
Hi Juan,
These patches are the result of Akio, Prarit, Alex and me working on
fixing
the
ia64 build of your tree. At this point the bare-metal Linux kernel
builds and
boots. The xen kernel builds but doesn't complete booting.
Nonetheless,
since
these patches seem to take us most of the way there, we'd like to
request
them
to be applied to your tree.
Thanks,
Aron
___
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] dom0-smp issue.
Hi Alex, I remembered I have sent out the patch to increase CONFIG_NR_CPUS to 16 for domain0 to enable SMP. It works well on Tiger4 platform but you said it would break HP's box. Seems need to think more about this issue before change:) Thanks Best Regards -Xiantao OTC,Intel Corporation Because Fujita already went home, I post console log instead of Fujita. Thanks. I suppose Isaku was right: your kernel was compiled with CONFIG_NR_CPUS=4, and according to the MADT, the fourth processor is not enabled. You should configure your kernel with 16 cpus. 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
[Xen-ia64-devel] [PATCH][IA64] Fix Qemu memory access beyond 3G
This patch intends to fix memory access beyond 3G for VTi domain. Currently VTi's memory beyond 3G was moved to 4G at build time. So it should be mapped correctly in qemu. If not, it will cause qemu's segmentation fault when guest use memory beyond 4G for DMA. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] Thanks Best Regards -Xiantao OTC,Intel Corporation fix_mem_access_beyond_3G.patch Description: fix_mem_access_beyond_3G.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH][Qemu]Free page_page after foreign map.
Seems no special reason for keeping page_array after foreign map. Free it to avoid memory leak in Qemu. Signed-off-by: Zhang xiantao [EMAIL PROTECTED] Thanks Best Regards -Xiantao OTC,Intel Corporation free_page_array.patch Description: free_page_array.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] Add buffer IO mechanism for Xen/VTi domain.
This patch adds buffer IO mechanism for Xen/VTi domain. It catches up with Xen/IA32 side. Current implementation can accelerate Windows geust's dense IO operations @ boot time. I divided it into two parts. One is only related to Qemu, and the other one is main body. Signed-off-by : Zhang xiantao [EMAIL PROTECTED] Thanks Best Regards -Xiantao OTC,Intel Corporation ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch]Add buffer IO mechanism for Xen/VTi domain[Part 2]
Main part. Signed-off-by: Zhang xiantao [EMAIL PROTECTED] Thanks Best Regards -Xiantao OTC,Intel Corporation buffer_io.patch Description: buffer_io.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Qemu]Fix for VTi's 3G memroy limit
This patch fixed 3G memory limit for VTi domain. Due to some logic change in Qemu, so initializing ram_size should be moved up. Signed-off-by : Zhang xiantao [EMAIL PROTECTED] Thanks Best Regards -Xiantao OTC,Intel Corporation fix_vti_3G.patch Description: fix_vti_3G.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] stacked pal call for VTi
Hi Tristan, I don't think this patch is needed for VTi domain. Oppositely, it may cause errors for stacked converntion calls. Because I recalled that stacked convention calls' parameters have been transferred into static ones before trapping into VMM in vPAL. I will check the code here and to see whether stack registers are tainted before the trap. Thanks, Xiantao 2007/2/16, [EMAIL PROTECTED] [EMAIL PROTECTED]: Hi, [I thought I have already sent this patch but I can't see it in the ml archive]. This patch implements stacked PAL call in VTi. 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 for compiling PV-on-HVM on IPF
Hi Tsunehisa, Unluckily, we met xen crash with this patch. Do you know which #Cset is stable enough for us to use VBD driver for HVM domain? :) Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DOI Tsunehisa Sent: 2007年2月27日 7:34 To: xen-ia64-devel Subject: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF Hi all, In the latest ia64-unstable tree, we can't build PV-on-HVM driver, because of a compile error about HYPERVISOR_grant_table_op(). I'll submit a patch to modify it. But, I don't have the test environment that I use at once, thus I did compile test only. 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] [Patch] Fix for compiling PV-on-HVM on IPF
Tsunehisa, Thanks for your information. Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 2007年2月27日 14:23 To: Zhang, Xiantao Cc: [EMAIL PROTECTED]; xen-ia64-devel Subject: Re: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF Hi, I've checked it. We'll have to modify the arch_memory_op code to follow dynamic grant table size feature in the hypervisor side. The latest change set (that is stable enough) is cs:13904, I think. This change set was confirmed by Kuwamura-san. I (Doi.Tsunehisa) said: Hi, Sorry, I'm bulding the test environment, now. I'll check it. Thanks You (xiantao.zhang) said: Hi Tsunehisa, Unluckily, we met xen crash with this patch. Do you know which #Cse t is stable enough for us to use VBD driver for HVM domain? :) Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DOI Tsunehisa Sent: 2007$BDj(B2$BTB(B27$BHU(B 7:34 To: xen-ia64-devel Subject: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF Hi all, In the latest ia64-unstable tree, we can't build PV-on-HVM driver, because of a compile error about HYPERVISOR_grant_table_op(). I'll submit a patch to modify it. But, I don't have the test environment that I use at once, thus I did compile test only. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] Let memory scrub done in time
Currently, memory scrub logic is done in SOFTIRQ, but it doesn't raise in time, so contiguous domain creation and destroy would come across fail. Xiantao patch.diff Description: patch.diff ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Patch] Let memory scrub done in time
Sorry for getting sign-off-by. Sign-off-by : Zhang xiantao [EMAIL PROTECTED] -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2007年3月29日 3:14 To: Zhang, Xiantao Cc: xen-ia64-devel Subject: Re: [Xen-ia64-devel] [Patch] Let memory scrub done in time On Wed, 2007-03-28 at 21:00 +0800, Zhang, Xiantao wrote: Currently, memory scrub logic is done in SOFTIRQ, but it doesn't raise in time, so contiguous domain creation and destroy would come across fail. Ok, but I need a Signed-off-by. 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] [PATCH] Always insert entry to VHPT's head, or double TLB miss occurs.
Patch: Always insert entry to VHPT head, or TLB miss will occur again although the translation exists in its collision chain. Signed-off-by: Zhang xiantao [EMAIL PROTECTED] Thanks Xiantao Insert entry to VHPT's head.patch Description: Insert entry to VHPT's head.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Always insert entry to VHPT's head, or double TLB miss occurs.
Hi Alex, Please drop the previous one. Don't need to disable IRQ during possible collision chain recycle, because it may need long time. Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2007年4月26日 18:00 To: xen-ia64-devel Subject: [Xen-ia64-devel] [PATCH] Always insert entry to VHPT's head,or double TLB miss occurs. Patch: Always insert entry to VHPT head, or TLB miss will occur again although the translation exists in its collision chain. Signed-off-by: Zhang xiantao [EMAIL PROTECTED] Thanks Xiantao diff.patch Description: diff.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Small fix for vpd size
New pal has fixed vpd size issue, so change its size to 64K. Xiantao vpd_64k.diff Description: vpd_64k.diff ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Small fix for vpd size
Hi Kan, This issue is just in early stage pal for internal use, and it doesn't exist in any release version, so you can use it safely with any version you got. Xiantao -Original Message- From: Masaki Kanno [mailto:[EMAIL PROTECTED] Sent: 2007年5月18日 12:09 To: Zhang, Xiantao; xen-ia64-devel Cc: Alex Williamson Subject: Re: [Xen-ia64-devel] Small fix for vpd size Hi Xiantao, What is a version number of new PAL? Does old PAL need 128K for VPD? Best regards, Kan New pal has fixed vpd size issue, so change its size to 64K. Xiantao ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] the xenLinux/IA64 upstream merge and Fedora.
Alex Williamson wrote: On Tue, 2007-12-04 at 10:58 +0900, Isaku Yamahata wrote: I'd like to share informations and opinions to avoid duplicate works. Please comments. Some questions. - Is anyone already working on it? - What code base is best to begin with? Although the official xenLinux/IA64 tree is http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg Does Fedora have any forward ported tree? This is definitely one of the tricky parts. Obviously we'll need to submit patches against upstream Linux, but we'll likely need to leverage the work of others for forward porting the core of the xen enabled components. The Fedora Xen kernel module may be a reasonable target, but there are probably lots of small architecture specific parts we can isolate into functional chunks and clean-up for upstream in the meantime. Some thoughts. - domU first and then dom0. the domu/IA64 part would be easy because MMU is fully virtualized on IA64. Yes, this would also allow us to start out focused on architecture specific parts while others solidify what the basis for dom0 looks like on upstream. - Coding Style The current code's style should be clean up. Definitely, although I think we've done a reasonable job matching Linux coding style for XenLinux files, I'm sure we'll find examples to the contrary. - Although xenLinux/x86 uses pv_ops, probably the machine vector should be considered at first. Then consider on the ia64 pv_ops. Yes, it's been unclear to me the extent to which ia64 needs pv_ops. We already have the xen machine vector and we may be able to expand the machine vector to incorporate a few more things where it makes sense. Then we need to see what pieces are left and whether it makes sense to create an ia64 pv_ops or implement more of the binary replacement type things we've discussed previously. - The kernel initialization might need to be revised. Especially the hypervisor detection and the initialization order. I think all of the xenlinux code should be carefully reviewed and re-evaluated as we try to get it upstream. This is also an opportunity to improve the code. - other VMM. Possibly kvm/ia64 or lguest/ia64 may have their opinion on paravirtualization. But their code aren't opened yet. This might make our merge easier or more difficult. Anyway we'll see. Yes, ia64 is at a bit of a disadvantage here since x86 has several implementations of paravirtualization to help tune their pv_ops. We should probably expect some of the interfaces to change over time as new PV guests are added, but we should try to solicit feedback from Jes and Xiantao as much as we can. Worked with kvm community guys in last two months, we almost completed kvm re-frame work. Currently, I have almost compelted kvm/ia64 rebase per the new framwork of kvm, although it is still need to refine by commnunity. So, after performing internal process, we will send out our kvm/ia64 patches to community soon. :) Thanks for your attention! Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] [Open GFW] Only use irq 10 and 11 for pci use.
Hi Tristan, This patch fixes possible failures on windows boot in some environment. Since current piix3 and piix4 in qemu only uses irq 10 and irq 11 for pci irqs, so here don't need to assign irq 5 and irq 6 for this purpose. IRQ 6 may conflict with the irq of legacy floppy disk controllers. diff -r f263d2bca359 edk2-sparse/EdkXenPkg/Dxe/XenAcpi/build.c --- a/edk2-sparse/EdkXenPkg/Dxe/XenAcpi/build.c Wed Dec 12 02:02:32 2007 +0100 +++ b/edk2-sparse/EdkXenPkg/Dxe/XenAcpi/build.c Tue Dec 25 14:59:34 2007 +0800 @@ -33,7 +33,7 @@ #define LSAPIC_ID(n) n extern int get_vcpu_nr (void); #define get_apic_mode() 1 -#define PCI_ISA_IRQ_MASK0x0c60U /* ISA IRQs 5,6,10,11 are PCI connected */ +#define PCI_ISA_IRQ_MASK0x0c00U /* ISA IRQs 10,11 are PCI connected */ #endif #define align16(sz) (((sz) + 15) ~15) diff Description: diff ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [PATCH] [Open GFW] Only use irq 10 and 11 for pci use.
Tristan Gingold wrote: On Tue, Dec 25, 2007 at 03:22:37PM +0800, Zhang, Xiantao wrote: Hi Tristan, This patch fixes possible failures on windows boot in some environment. Since current piix3 and piix4 in qemu only uses irq 10 and irq 11 for pci irqs, so here don't need to assign irq 5 and irq 6 for this purpose. IRQ 6 may conflict with the irq of legacy floppy disk controllers. I fear that with only 2 bits set, only INTA and INTB will be set. However from piix_pci-dm.c, it appears we don't really use INTA/D mapping. Am I right ? Yes, you are right. Seems all pci device should get an irq 16 from the algorithm. But for KVM, we also need to use assigned irqs for INTA-INTD. But irq 6 shouldn't use for this purpose, it may confilicts with floppy disk controller. Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [PATCH] [Open GFW] Only use irq 10 and 11 for pci use.
Tristan Gingold wrote: On Tue, Dec 25, 2007 at 03:22:37PM +0800, Zhang, Xiantao wrote: Hi Tristan, This patch fixes possible failures on windows boot in some environment. Since current piix3 and piix4 in qemu only uses irq 10 and irq 11 for pci irqs, so here don't need to assign irq 5 and irq 6 for this purpose. IRQ 6 may conflict with the irq of legacy floppy disk controllers. Hi, I was about to commit this patch, but shouldn't EdkQemuPkg/Pei/BochsPciScan/BochsPciScan.c be updated too ? Yes. Sure to change. Maybe we need to consolidate these two definitions to one. Do you know how to ? Thanks Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] VHPI restore mechanism at save/restore
Hi,Isaku I have a question about the mechanism for save/restore vhpi. In current save/restore code, vhpi register is only saved and restored by vlsapic_save/load, but it maybe not enough for ensuring correctness. IMO, we need to call PAL_VPS_SET_PENDING_INTERRUPT again to set it， and make cpu aware of its value. Do I miss something ? :) Thanks Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] VHPI restore mechanism at save/restore
Isaku Yamahata wrote: On Fri, Feb 01, 2008 at 06:11:13PM +0800, Zhang, Xiantao wrote: Hi,Isaku I have a question about the mechanism for save/restore vhpi. In current save/restore code, vhpi register is only saved and restored by vlsapic_save/load, but it maybe not enough for ensuring correctness. IMO, we need to call PAL_VPS_SET_PENDING_INTERRUPT again to set it， and make cpu aware of its value. Do I miss something ? :) Please notice the line in vlsapic_load() v-arch.irq_new_pending = 1; /* to force checking irq */ Why need to set the force check here? Any special reasons or scenarios which need it ? :) and see leave_hypervisor_tail() which is always called before entering VTi guest. leave_hypervisor_tail() eventually calls PAL_VPS_SET_PENDING_INTERRUPT. At least this is my intention. Do you find any path where it isn't called? The force check may workaround the lost VHPI, so it should work. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] MINSTATE_PHYS?
Akio Takebe wrote: Hi, Eddie and Kaz I did a quick grep and find MINSTATE_PHYS is never defined in xenlinux. Xen mca code did. Anything missed? The minstate.h is a little old, it seems to be around linux-2.6.9. Current linux-xen is 2.6.18, so the code may be not nessesary. Kaz, do you know about it? Hi, Akio all Attached the patch did some cleanups. Please review. Xiantao pv_ops_cleanup1.patch Description: pv_ops_cleanup1.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: paravirt_ops support in IA64
Dong, Eddie wrote: In X86, there are another enhancement (dynamic patching) base on pv_ops. The purpose is to improve cpu predication by converting indriect function call to direct function call for both C ASM code. We may take similar approach some time later too. We really need advices from community before we jump into coding. CC some active members that I though may be interested in pv_ops since KVM-IA64 mailinglist doesn;t exist yet. Hi, Eddie we just created the kvm-ia64-devel mailing list, and cc to the guys from this list who maybe interested in this topic. If you or other guys who are interested in kvm-ia64-devel or pv_virt_ops for ia64, please subscribe it here http://kvm.qumranet.com/kvmwiki/Lists%2C_IRC Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] MINSTATE_PHYS?
Hi, Alex What's your opinion about this cleanup patch ? Thanks Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2008年2月2日 10:17 To: Akio Takebe; Dong, Eddie; xen-ia64-devel Cc: Alex Williamson Subject: RE: [Xen-ia64-devel] MINSTATE_PHYS? Akio Takebe wrote: Hi, Eddie and Kaz I did a quick grep and find MINSTATE_PHYS is never defined in xenlinux. Xen mca code did. Anything missed? The minstate.h is a little old, it seems to be around linux-2.6.9. Current linux-xen is 2.6.18, so the code may be not nessesary. Kaz, do you know about it? Hi, Akio all Attached the patch did some cleanups. Please review. Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [PATCH] [Open GFW] Only use irq 10 and 11 for pci use.
Hi, Tristan Thank you! Attached. Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 2008年2月20日 0:40 To: Zhang, Xiantao Cc: Tristan Gingold; xen-ia64-devel Subject: RE: [PATCH] [Open GFW] Only use irq 10 and 11 for pci use. Quoting Zhang, Xiantao [EMAIL PROTECTED]: Tristan Gingold wrote: On Tue, Dec 25, 2007 at 03:22:37PM +0800, Zhang, Xiantao wrote: Hi Tristan, This patch fixes possible failures on windows boot in some environment. Since current piix3 and piix4 in qemu only uses irq 10 and irq 11 for pci irqs, so here don't need to assign irq 5 and irq 6 for this purpose. IRQ 6 may conflict with the irq of legacy floppy disk controllers. Hi, I was about to commit this patch, but shouldn't EdkQemuPkg/Pei/BochsPciScan/BochsPciScan.c be updated too ? Yes. Sure to change. Maybe we need to consolidate these two definitions to one. Do you know how to ? Hi, old issue... If you can send me a changeset that changes both BochsPciScan and build.c I will be happy to apply it. Tristan. Diff Description: Diff ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: tools/ioemu/ia64.ld ?
Aron Griffis wrote: Hi, Does anybody know why xen's ioemu has its own custom linker script? This was inherited from qemu, apparently contributed by David Mosberger over 2 years ago. It's been patched for kvm (see http://www.mail-archive.com/[EMAIL PROTECTED]/msg10306.htm l) but as far as I can see, that's essentially bringing part of it up to date with the default linker script in binutils. Hi, Aron The fix for kvm is just for moving the code section to region 2, and has no other purposes :) I'm asking about this because it's the last thing in the way of a clean cross build of xen tools. You can see the build failure at http://markmail.org/message/zowwwfs3mdipseiv The first failure in that message is because the custom linker script was using the wrong library directories. That is easily fixed. The second build failure is opaque to me: ../../xenstore/libxenstore.so: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status However, if I comment out the linker script in the Makefile then the build works, and hvm domains seem to run fine built with the default linker script. When I diff ia64.ld to Debian's /usr/lib/ldscripts/elf64_ia64.x I don't see anything significant, but I'm not an expert in this area. Can anybody tell me why we need this? If not, I'll submit a patch to remove it. I guess you can remove it and use the default, since ia64 arch has no special requirment for it. Xiantao ___ 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] [Q] How to download pv_ops git tree
Akio Takebe wrote: Hi, Eddie Thank you. I am not a git expert either :( But would you please check if the http_proxy is set correctly? Xiantao'tree support git port I think. Yes, I did export http_proxy=http://xxx.yyy.zzz:;, then git clone, but I cannot download it. I could get index.html with wget http://people.valinux.co.jp/~yamahata/xen-ia64/linux-2.6-xen-ia64.git; Hi, Akio We also meet the same issue days ago. Maybe you can use the mirror I set up in repo.or.cz. It works well, if you are behind the http_proxy . It is easy to use, clone http://repo.or.cz/w/pv_ops_mirror.git, and checkout the related branches :) Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Q] How to download pv_ops git tree
Akio Takebe wrote: Hi, Xiantao-san We also meet the same issue days ago. Maybe you can use the mirror I set up in repo.or.cz. It works well, if you are behind the http_proxy . It is easy to use, clone http://repo.or.cz/w/pv_ops_mirror.git, and checkout the related branches :) Xiantao Thnak you. I could download your git tree with git clone git://repo.or.cz/pv_ops_mirror.git Good news! :) We may be not able to use http protocol of git... Thank you for always helping us. 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] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3f... Status --- no new issue, report 3 old bugs
Isaku Yamahata wrote: On Fri, Oct 24, 2008 at 09:59:58AM +0800, Zhang, Jingke wrote: 3. IPF-Xen can not boot up domain with dom_id 62 (not regression, should be there for a long time) Long ago, I posted the patch to address this issue. Probably there are two ways. (Is there other better way?) a.) abandon the rid partitioning, and flush mTLB every time vcpu context switch. Current kvm adopts this method, we didn't find any performance regression through benchmark. But sine the architecture difference between xen and kvm, so maybe should investigate more through enough benchmark data. (some bits of rid space needs to be reserved for real mode emulation.) b.) keep the rid partitioning and allow rid collision. When vcpu context switch, check the rid collision and flush mTLB if necessary. Benchmark would be necessary to decide which one is better and to estimate performance degradation. I implemented b). However no one has implemented a). So no further step was taken. I thought Jingke isn't saying this topic. What he found maybe he failed to create the domain when the domain is created and destoryed continuously for more 62 times. Seems the issue is from the the algorithm for deallocating rid blocks doesn't work, when destroying the guest. Xiantao thanks, ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3f... Status --- no new issue, report 3 old bugs
Isaku Yamahata wrote: On Tue, Oct 28, 2008 at 12:12:45PM +0900, Isaku Yamahata wrote: I thought Jingke isn't saying this topic. What he found maybe he failed to create the domain when the domain is created and destoryed continuously for more 62 times. Seems the issue is from the the algorithm for deallocating rid blocks doesn't work, when destroying the guest. Oh I see. Thank you for the explanation. Could you try the following patch? IA64: fix XENMEM_add_to_physmap with XENMAPSPACE_mfn. page reference count was leaked so that hvm domain wasn't freed. This patch fixes it. Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c --- a/xen/arch/ia64/xen/mm.c +++ b/xen/arch/ia64/xen/mm.c @@ -3365,7 +3365,6 @@ arch_memory_op(int op, XEN_GUEST_HANDLE( /* Map at new location. */ /* Here page-count_info = PGC_allocated | N where N = 1*/ __guest_physmap_add_page(d, xatp.gpfn, mfn); -page = NULL; /* prevent put_page() */ out: domain_unlock(d); Hi, Isuka Good catch! That can explain why deallocation algorithm doesn't work. Thanks Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: Fix an memory attribute issue.
PATCH: Fix an memory attribute issue. We should ensure Qemu and Guest use same attribute for accessing the VGA ram, otherwise, host may hang. Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r a6b1be5a83de xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 11:02:23 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 16:14:34 2008 +0800 @@ -522,7 +522,7 @@ * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma == VA_MATTR_NATPAGE) +if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); mem_attr_fix.patch Description: mem_attr_fix.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18694, Linux#706, ioemu#b4d410a1.. Status --- 1 new
Isaku Yamahata wrote: On Wed, Oct 29, 2008 at 04:10:50PM +0800, Zhang, Jingke wrote: Hi all, There is one new regression in Cset#18691. With latest Cset#18694, all the case can pass! One regression between Cset#18688 and Cset#18691: == 1. Qemu graphic mode display abnormally while booting VTI_Windows and Linux-Xwin. This issue existed in either sdl=1 or vnc=1 mode. And this issue does not exist with Cset#18688. Hmm, I suspect the change set 18689:7ad8c47f5c4b. But I'm not sure. Hi, Isaku We found the cause,maybe rootcause. 18669 may has a poetentail issue, but doesn't lead to the issue. We found valid_mfn() doesn't work in its way, and seems it is buggy. I have no enough time to debug it, but the following patch should fix the current issue. diff -r a6b1be5a83de xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 11:02:23 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 13:47:08 2008 +0800 @@ -522,7 +522,7 @@ * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma == VA_MATTR_NATPAGE) +if (!(maddr 61) phy_pte.ma == VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18694, Linux#706, ioemu#b4d410a1.. Status --- 1 new
Zhang, Xiantao wrote: Isaku Yamahata wrote: On Wed, Oct 29, 2008 at 04:10:50PM +0800, Zhang, Jingke wrote: Hi all, There is one new regression in Cset#18691. With latest Cset#18694, all the case can pass! One regression between Cset#18688 and Cset#18691: == 1. Qemu graphic mode display abnormally while booting VTI_Windows and Linux-Xwin. This issue existed in either sdl=1 or vnc=1 mode. And this issue does not exist with Cset#18688. Hmm, I suspect the change set 18689:7ad8c47f5c4b. But I'm not sure. Hi, Isaku We found the cause,maybe rootcause. 18669 may has a poetentail issue, but doesn't lead to the issue. We found valid_mfn() doesn't work in its way, and seems it is buggy. I have no enough time to debug it, but the following patch should fix the current issue. diff -r a6b1be5a83de xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 11:02:23 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 13:47:08 2008 +0800 @@ -522,7 +522,7 @@ * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma == VA_MATTR_NATPAGE) +if (!(maddr 61) phy_pte.ma == VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); Xiantao Oops. .. Forget to rebase to tip. Should be: diff -r 4a5acf020c0f xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 11:51:55 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 14:13:27 2008 +0800 @@ -522,7 +522,7 @@ * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma != VA_MATTR_NATPAGE) +if (!(maddr 61) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18694, Linux#706, ioemu#b4d410a1.. Status --- 1 new
I found the reason why mfn_valid behaves abnormally. We should mask out
TLB_TRACK bits from p2m entry before using it as mfn_valid's parameter.
diff -r 4a5acf020c0f xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 21:57:38 2008 +0800
@@ -522,7 +522,8 @@
* which is required by vga acceleration since qemu maps shared
* vram buffer with WB.
*/
-if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma != VA_MATTR_NATPAGE)
+if (mfn_valid((maddr _PAGE_PPN_MASK) PAGE_SHIFT)
+phy_pte.ma != VA_MATTR_NATPAGE)
phy_pte.ma = VA_MATTR_WB;
maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK);
diff -r 4a5acf020c0f xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cThu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/xen/mm.cThu Oct 30 21:57:38 2008 +0800
@@ -926,7 +926,8 @@
/* in HVM guest, when VTD is enabled,
* P2M entry may change from _PAGE_IO type to real MMIO page
*/
-if(VMX_DOMAIN(d-vcpu[0]) (pte_val(ret_pte) _PAGE_IO)) {
+if(is_hvm_domain(d) (pte_val(ret_pte) _PAGE_IO)
+ !mfn_valid(physaddr PAGE_SHIFT)) {
old_pte = ret_pte;
goto again_hvm_page_io;
}
Zhang, Xiantao wrote:
Isaku Yamahata wrote:
On Wed, Oct 29, 2008 at 04:10:50PM +0800, Zhang, Jingke wrote:
Hi all,
There is one new regression in Cset#18691. With latest
Cset#18694, all the case can pass!
One regression between Cset#18688 and Cset#18691: ==
1. Qemu graphic mode display abnormally while booting
VTI_Windows and Linux-Xwin. This issue existed in either
sdl=1 or vnc=1 mode. And this issue does not exist with Cset#18688.
Hmm, I suspect the change set 18689:7ad8c47f5c4b. But I'm not sure.
Hi, Isaku
We found the cause,maybe rootcause. 18669 may has a poetentail
issue, but doesn't lead to the issue. We found valid_mfn() doesn't
work in its way, and seems it is buggy. I have no enough time to
debug it, but the following patch should fix the current issue.
diff -r a6b1be5a83de xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 11:02:23 2008 +0900
+++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 13:47:08 2008 +0800
@@ -522,7 +522,7 @@
* which is required by vga acceleration since qemu maps shared
* vram buffer with WB.
*/
-if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma ==
VA_MATTR_NATPAGE) +if (!(maddr 61) phy_pte.ma ==
VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB;
maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr
~PAGE_MASK);
Xiantao
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
fix-vga-abnormal.patch
Description: fix-vga-abnormal.patch
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18694, Linux#706, ioemu#b4d410a1.. Status --- 1 new
Here it is! :)
PATCH: Fix HVM VGA abnormal.
Conversion from p2m entry to physical address, it needs to use
_PAGE_PPN_MASK to mask out some bits which are used by other
purposes by p2m entry.
Sign-off-by : Xiantao Zhang [EMAIL PROTECTED]
diff -r 4a5acf020c0f xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 21:57:38 2008 +0800
@@ -522,7 +522,8 @@
* which is required by vga acceleration since qemu maps shared
* vram buffer with WB.
*/
-if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma != VA_MATTR_NATPAGE)
+if (mfn_valid((maddr _PAGE_PPN_MASK) PAGE_SHIFT)
+phy_pte.ma != VA_MATTR_NATPAGE)
phy_pte.ma = VA_MATTR_WB;
maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK);
diff -r 4a5acf020c0f xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cThu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/xen/mm.cThu Oct 30 21:57:38 2008 +0800
@@ -926,7 +926,8 @@
/* in HVM guest, when VTD is enabled,
* P2M entry may change from _PAGE_IO type to real MMIO page
*/
-if(VMX_DOMAIN(d-vcpu[0]) (pte_val(ret_pte) _PAGE_IO)) {
+if(is_hvm_domain(d) (pte_val(ret_pte) _PAGE_IO)
+ !mfn_valid(physaddr PAGE_SHIFT)) {
old_pte = ret_pte;
goto again_hvm_page_io;
}
-Original Message-
From: Isaku Yamahata [mailto:[EMAIL PROTECTED]
Sent: Friday, October 31, 2008 9:46 AM
To: Zhang, Xiantao
Cc: Zhang, Jingke; xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] Xen/IPF Unstable CS#18694, Linux#706,
ioemu#b4d410a1.. Status --- 1 new
Oh great. Thank you for debugging.
Could you provide your signed-off-by?
On Thu, Oct 30, 2008 at 11:07:56PM +0800, Zhang, Xiantao wrote:
I found the reason why mfn_valid behaves abnormally. We should mask out
TLB_TRACK bits from p2m entry before using it as mfn_valid's parameter.
diff -r 4a5acf020c0f xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.cThu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/vmx/vtlb.cThu Oct 30 21:57:38 2008 +0800
@@ -522,7 +522,8 @@
* which is required by vga acceleration since qemu maps shared
* vram buffer with WB.
*/
-if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma != VA_MATTR_NATPAGE)
+if (mfn_valid((maddr _PAGE_PPN_MASK) PAGE_SHIFT)
+ phy_pte.ma != VA_MATTR_NATPAGE)
phy_pte.ma = VA_MATTR_WB;
maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK);
diff -r 4a5acf020c0f xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Thu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/xen/mm.c Thu Oct 30 21:57:38 2008 +0800
@@ -926,7 +926,8 @@
/* in HVM guest, when VTD is enabled,
* P2M entry may change from _PAGE_IO type to real MMIO page
*/
-if(VMX_DOMAIN(d-vcpu[0]) (pte_val(ret_pte) _PAGE_IO)) {
+if(is_hvm_domain(d) (pte_val(ret_pte) _PAGE_IO)
+ !mfn_valid(physaddr PAGE_SHIFT)) {
old_pte = ret_pte;
goto again_hvm_page_io;
}
Zhang, Xiantao wrote:
Isaku Yamahata wrote:
On Wed, Oct 29, 2008 at 04:10:50PM +0800, Zhang, Jingke wrote:
Hi all,
There is one new regression in Cset#18691. With latest
Cset#18694, all the case can pass!
One regression between Cset#18688 and Cset#18691: ==
1. Qemu graphic mode display abnormally while booting
VTI_Windows and Linux-Xwin. This issue existed in either
sdl=1 or vnc=1 mode. And this issue does not exist with Cset#18688.
Hmm, I suspect the change set 18689:7ad8c47f5c4b. But I'm not sure.
Hi, Isaku
We found the cause,maybe rootcause. 18669 may has a poetentail
issue, but doesn't lead to the issue. We found valid_mfn() doesn't
work in its way, and seems it is buggy. I have no enough time to
debug it, but the following patch should fix the current issue.
diff -r a6b1be5a83de xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 11:02:23 2008 +0900
+++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 13:47:08 2008 +0800
@@ -522,7 +522,7 @@
* which is required by vga acceleration since qemu maps shared
* vram buffer with WB.
*/
-if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma ==
VA_MATTR_NATPAGE) +if (!(maddr 61) phy_pte.ma ==
VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB;
maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr
~PAGE_MASK);
Xiantao
___
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
--
yamahata
fix-vga-abnormal.patch
Description: fix-vga-abnormal.patch
[Xen-ia64-devel] [PATCH] Fix vti guests broken issue.
PATCH : Fix vti guests broken issue. mfn_valid should use machine physical pfn, not guest physical pfn. Sign-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Fri Nov 07 10:35:11 2008 +0800 @@ -522,7 +522,7 @@ static u64 translate_phy_pte(VCPU *v, u6 * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(pte_pfn(__pte(pte))) phy_pte.ma != VA_MATTR_NATPAGE) +if (mfn_valid(pte_pfn(__pte(maddr))) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); vti-broken.patch Description: vti-broken.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue.
Yes. Should be addressed. -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 11:03 AM To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue. Oh, my bad. Thank you for debugging. I applied and pushed out. Does this fixed the issue you repoted? thanks, On Fri, Nov 07, 2008 at 10:42:57AM +0800, Zhang, Xiantao wrote: PATCH : Fix vti guests broken issue. mfn_valid should use machine physical pfn, not guest physical pfn. Sign-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.cThu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.cFri Nov 07 10:35:11 2008 +0800 @@ -522,7 +522,7 @@ static u64 translate_phy_pte(VCPU *v, u6 * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(pte_pfn(__pte(pte))) phy_pte.ma != VA_MATTR_NATPAGE) +if (mfn_valid(pte_pfn(__pte(maddr))) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); ___ 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] [PATCH] Fix vti guests broken issue.
But another thing to meation, why mfn_valid with invalid parameter will incur the fault? Seems mfn_valid has something wrong, I have no enough time to find the cause. Is it a known issue ? Or mfn_valid has some limitation ? Thanks Xiantao Zhang, Xiantao wrote: Yes. Should be addressed. -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 11:03 AM To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue. Oh, my bad. Thank you for debugging. I applied and pushed out. Does this fixed the issue you repoted? thanks, On Fri, Nov 07, 2008 at 10:42:57AM +0800, Zhang, Xiantao wrote: PATCH : Fix vti guests broken issue. mfn_valid should use machine physical pfn, not guest physical pfn. Sign-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Fri Nov 07 10:35:11 2008 +0800 @@ -522,7 +522,7 @@ static u64 translate_phy_pte(VCPU *v, u6 * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(pte_pfn(__pte(pte))) phy_pte.ma != VA_MATTR_NATPAGE) +if (mfn_valid(pte_pfn(__pte(maddr))) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); ___ 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 vti guests broken issue.
Isaku Yamahata wrote: On Fri, Nov 07, 2008 at 11:33:43AM +0800, Zhang, Xiantao wrote: But another thing to meation, why mfn_valid with invalid parameter will incur the fault? Seems mfn_valid has something wrong, I have no enough time to find the cause. Is it a known issue ? Or mfn_valid has some limitation ? mfn_valid() with invalid parameter shouldn't cause panic. It may cause tlb miss fault, but the fault should be handled specially by frametable_fault in ivt.S and should be recovered resulting in mfn_valid() returning false. I agree with you that there's something wrong in mfn_valid() I haven't aware of the issue. Okay, if so, frametable_fault maybe not handled in a correct way in vmx_ivt.S. Xiantao thanks, Thanks Xiantao Zhang, Xiantao wrote: Yes. Should be addressed. -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 11:03 AM To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue. Oh, my bad. Thank you for debugging. I applied and pushed out. Does this fixed the issue you repoted? thanks, On Fri, Nov 07, 2008 at 10:42:57AM +0800, Zhang, Xiantao wrote: PATCH : Fix vti guests broken issue. mfn_valid should use machine physical pfn, not guest physical pfn. Sign-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Fri Nov 07 10:35:11 2008 +0800 @@ -522,7 +522,7 @@ static u64 translate_phy_pte(VCPU *v, u6 * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(pte_pfn(__pte(pte))) phy_pte.ma != VA_MATTR_NATPAGE) +if (mfn_valid(pte_pfn(__pte(maddr))) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); ___ 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 vti guests broken issue.
Hi, Isaku Attached patch should fix the issue. Paravirtualized ivt and HVM ivt share the code for frametable_miss handling, but they have different assumptions for registers useage. IPSR is savded in r21 at paravirtualized side, but r29 is used for HVM side. This patch uniform them to use r29 for ipsr save. Thanks Xiantao PATCH: Fix frametable_miss handling for HVM guests. For hvm guests, hypervisor use mfn_valid to check mfn, but it will incur weird faults. It is becasue ipsr is saved in r29, but frametalbe miss assumes saved in r21. Signed-off-by Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.S Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vmx_ivt.S Fri Nov 07 15:31:26 2008 +0800 @@ -356,7 +356,7 @@ vmx_alt_dtlb_miss_vmm: // Test for the address of virtual frame_table shr r22=r16,56;; cmp.eq p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22 -(p8)br.cond.sptk frametable_miss ;; +(p8)br.cond.sptk frametable_miss ;; //Make sure ipsr is saved in r29 #endif movl r17=PAGE_KERNEL mov r20=cr.isr diff -r f6795589ef82 xen/arch/ia64/xen/ivt.S --- a/xen/arch/ia64/xen/ivt.S Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/xen/ivt.S Fri Nov 07 15:31:26 2008 +0800 @@ -184,10 +184,10 @@ late_alt_dtlb_miss: late_alt_dtlb_miss: mov r20=cr.isr movl r17=PAGE_KERNEL - mov r21=cr.ipsr + mov r29=cr.ipsr movl r19=(((1 IA64_MAX_PHYS_BITS) - 1) ~0xfff) ;; - extr.u r23=r21,IA64_PSR_CPL0_BIT,2 // extract psr.cpl + extr.u r23=r29,IA64_PSR_CPL0_BIT,2 // extract psr.cpl and r22=IA64_ISR_CODE_MASK,r20 // get the isr.code field tbit.nz p6,p7=r20,IA64_ISR_SP_BIT // is speculation bit on? extr.u r18=r16,XEN_VIRT_UC_BIT,1// extract UC bit @@ -234,7 +234,7 @@ late_alt_dtlb_miss: br.cond.spnt page_fault ;; alt_dtlb_miss_identity_map: - dep r21=-1,r21,IA64_PSR_ED_BIT,1 + dep r29=-1,r29,IA64_PSR_ED_BIT,1 or r19=r19,r17 // insert PTE control bits into r19 mov cr.itir=r20 // set itir with cleared key ;; @@ -243,7 +243,7 @@ alt_dtlb_miss_identity_map: cmp.eq.or p8,p0=0x18,r22// Region 6 is UC for EFI ;; (p8) dep r19=-1,r19,4,1 // set bit 4 (uncached) if access to UC area -(p6) mov cr.ipsr=r21 +(p6) mov cr.ipsr=r29 ;; (p7) itc.d r19 // insert the TLB entry mov pr=r31,-1 @@ -288,17 +288,17 @@ GLOBAL_ENTRY(frametable_miss) rfi END(frametable_miss) -ENTRY(frametable_fault) +ENTRY(frametable_fault)//ipsr saved in r29 before coming here! ssm psr.dt // switch to using virtual data addressing mov r18=cr.iip movl r19=ia64_frametable_probe ;; cmp.eq p6,p7=r18,r19// is faulting addrress ia64_frametable_probe? mov r8=0// assumes that 'probe.r' uses r8 - dep r21=-1,r21,IA64_PSR_RI_BIT+1,1 // return to next instruction in + dep r29=-1,r29,IA64_PSR_RI_BIT+1,1 // return to next instruction in // bundle 2 ;; -(p6) mov cr.ipsr=r21 +(p6) mov cr.ipsr=r29 mov r19=4 // FAULT(4) (p7) br.spnt.few dispatch_to_fault_handler ;; Isaku Yamahata wrote: On Fri, Nov 07, 2008 at 11:33:43AM +0800, Zhang, Xiantao wrote: But another thing to meation, why mfn_valid with invalid parameter will incur the fault? Seems mfn_valid has something wrong, I have no enough time to find the cause. Is it a known issue ? Or mfn_valid has some limitation ? mfn_valid() with invalid parameter shouldn't cause panic. It may cause tlb miss fault, but the fault should be handled specially by frametable_fault in ivt.S and should be recovered resulting in mfn_valid() returning false. I agree with you that there's something wrong in mfn_valid() I haven't aware of the issue. thanks, Thanks Xiantao Zhang, Xiantao wrote: Yes. Should be addressed. -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 11:03 AM To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue. Oh, my bad. Thank you for debugging. I applied and pushed out. Does this fixed the issue you repoted? thanks, On Fri, Nov 07, 2008 at 10:42:57AM +0800, Zhang, Xiantao wrote: PATCH : Fix vti guests broken issue. mfn_valid should use machine physical pfn, not guest physical pfn. Sign-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Fri Nov 07 10:35:11 2008 +0800 @@ -522,7 +522,7 @@ static u64 translate_phy_pte(VCPU *v, u6 * which
RE: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue.
Okay, Updated :) Xiantao PATCH: Fix frametable_miss handling for HVM guests. For hvm guests, hypervisor use mfn_valid to check mfn, but it will incur weird faults. It is becasue ipsr is saved in r29, but frametalbe miss assumes saved in r21. Signed-off-by Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.S Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vmx_ivt.S Fri Nov 07 16:35:55 2008 +0800 @@ -343,7 +343,7 @@ END(vmx_alt_itlb_miss) // 0x1000 Entry 4 (size 64 bundles) Alt DTLB (7,46) ENTRY(vmx_alt_dtlb_miss) VMX_DBG_FAULT(4) -mov r29=cr.ipsr +mov r29=cr.ipsr//frametable_miss needs ipsr is saved in r29. mov r31=pr adds r22=IA64_VCPU_MMU_MODE_OFFSET, r21 ;; @@ -356,7 +356,7 @@ vmx_alt_dtlb_miss_vmm: // Test for the address of virtual frame_table shr r22=r16,56;; cmp.eq p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22 -(p8)br.cond.sptk frametable_miss ;; +(p8)br.cond.sptk frametable_miss ;; //Make sure ipsr is saved in r29 #endif movl r17=PAGE_KERNEL mov r20=cr.isr diff -r f6795589ef82 xen/arch/ia64/xen/ivt.S --- a/xen/arch/ia64/xen/ivt.S Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/xen/ivt.S Fri Nov 07 16:35:55 2008 +0800 @@ -184,10 +184,12 @@ late_alt_dtlb_miss: late_alt_dtlb_miss: mov r20=cr.isr movl r17=PAGE_KERNEL - mov r21=cr.ipsr + mov r29=cr.ipsr // frametable_miss is shared by paravirtual and HVM sides + // and it assumes ipsr is saved in r29. If change the + // registers usage here, please check both sides! movl r19=(((1 IA64_MAX_PHYS_BITS) - 1) ~0xfff) ;; - extr.u r23=r21,IA64_PSR_CPL0_BIT,2 // extract psr.cpl + extr.u r23=r29,IA64_PSR_CPL0_BIT,2 // extract psr.cpl and r22=IA64_ISR_CODE_MASK,r20 // get the isr.code field tbit.nz p6,p7=r20,IA64_ISR_SP_BIT // is speculation bit on? extr.u r18=r16,XEN_VIRT_UC_BIT,1// extract UC bit @@ -234,7 +236,7 @@ late_alt_dtlb_miss: br.cond.spnt page_fault ;; alt_dtlb_miss_identity_map: - dep r21=-1,r21,IA64_PSR_ED_BIT,1 + dep r29=-1,r29,IA64_PSR_ED_BIT,1 or r19=r19,r17 // insert PTE control bits into r19 mov cr.itir=r20 // set itir with cleared key ;; @@ -243,7 +245,7 @@ alt_dtlb_miss_identity_map: cmp.eq.or p8,p0=0x18,r22// Region 6 is UC for EFI ;; (p8) dep r19=-1,r19,4,1 // set bit 4 (uncached) if access to UC area -(p6) mov cr.ipsr=r21 +(p6) mov cr.ipsr=r29 ;; (p7) itc.d r19 // insert the TLB entry mov pr=r31,-1 @@ -288,17 +290,17 @@ GLOBAL_ENTRY(frametable_miss) rfi END(frametable_miss) -ENTRY(frametable_fault) +ENTRY(frametable_fault)//ipsr saved in r29 before coming here! ssm psr.dt // switch to using virtual data addressing mov r18=cr.iip movl r19=ia64_frametable_probe ;; cmp.eq p6,p7=r18,r19// is faulting addrress ia64_frametable_probe? mov r8=0// assumes that 'probe.r' uses r8 - dep r21=-1,r21,IA64_PSR_RI_BIT+1,1 // return to next instruction in + dep r29=-1,r29,IA64_PSR_RI_BIT+1,1 // return to next instruction in // bundle 2 ;; -(p6) mov cr.ipsr=r21 +(p6) mov cr.ipsr=r29 mov r19=4 // FAULT(4) (p7) br.spnt.few dispatch_to_fault_handler ;; Isaku Yamahata wrote: On Fri, Nov 07, 2008 at 03:47:10PM +0800, Zhang, Xiantao wrote: Hi, Isaku Attached patch should fix the issue. Paravirtualized ivt and HVM ivt share the code for frametable_miss handling, but they have different assumptions for registers useage. IPSR is savded in r21 at paravirtualized side, but r29 is used for HVM side. This patch uniform them to use r29 for ipsr save. Oh great! That explains why mfn_valid() didn't work and the patch looks good. Could you please add the comment above late_alt_dtlb_miss why the r29 is used instead of r21 in ivt.S? thanks, Thanks Xiantao PATCH: Fix frametable_miss handling for HVM guests. For hvm guests, hypervisor use mfn_valid to check mfn, but it will incur weird faults. It is becasue ipsr is saved in r29, but frametalbe miss assumes saved in r21. Signed-off-by Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.SThu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vmx_ivt.SFri Nov 07 15:31:26 2008 +0800 @@ -356,7 +356,7 @@ vmx_alt_dtlb_miss_vmm: // Test for the address of virtual frame_table shr r22=r16,56;; cmp.eq p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22 -(p8)br.cond.sptk frametable_miss ;; +(p8)br.cond.sptk frametable_miss ;; //Make sure ipsr
[Xen-ia64-devel] [PATCH] Fix a bug for XEN_VIRT_UC_BIT use.
Fix a bug for XEN_VIRT_UC_BIT use. Signed-off-by : Zhang Xiantao [EMAIL PROTECTED] diff -r 9bc00e9716cd xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.S Fri Nov 07 19:34:59 2008 +0900 +++ b/xen/arch/ia64/vmx/vmx_ivt.S Mon Nov 17 11:12:58 2008 +0800 @@ -314,7 +314,7 @@ vmx_alt_itlb_miss_vmm: movl r19=(((1 IA64_MAX_PHYS_BITS) - 1) ~0xfff) ;; and r19=r19,r16 // clear ed, reserved bits, and PTE control bits -extr.u r18=r16,XEN_VIRT_UC_BIT, 15// extract UC bit +extr.u r18=r16,XEN_VIRT_UC_BIT, 1// extract UC bit ;; or r19=r17,r19 // insert PTE control bits into r19 mov r20=IA64_GRANULE_SHIFT2 Fix-XEN_VIRT_UC_BIT-use.patch Description: Fix-XEN_VIRT_UC_BIT-use.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix a bug for XEN_VIRT_UC_BIT use.
Yes, only bit 0 is used for dep. Xiantao Isaku Yamahata wrote: Hi. This patch itself looks okay. Just for confirming. This patch doesn't affect the result because the following line sees only the lsb 0 bit of r18. Correct? extr.u r18=r16,XEN_VIRT_UC_BIT, 15// extract UC bit ... dep r19=r18,r19,4,1 // set bit 4 (uncached) if the access was to UC region On Mon, Nov 17, 2008 at 11:20:49AM +0800, Zhang, Xiantao wrote: Fix a bug for XEN_VIRT_UC_BIT use. Signed-off-by : Zhang Xiantao [EMAIL PROTECTED] diff -r 9bc00e9716cd xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.SFri Nov 07 19:34:59 2008 +0900 +++ b/xen/arch/ia64/vmx/vmx_ivt.SMon Nov 17 11:12:58 2008 +0800 @@ -314,7 +314,7 @@ vmx_alt_itlb_miss_vmm: movl r19=(((1 IA64_MAX_PHYS_BITS) - 1) ~0xfff) ;; and r19=r19,r16 // clear ed, reserved bits, and PTE control bits -extr.u r18=r16,XEN_VIRT_UC_BIT, 15// extract UC bit +extr.u r18=r16,XEN_VIRT_UC_BIT, 1// extract UC bit ;; or r19=r17,r19 // insert PTE control bits into r19 mov r20=IA64_GRANULE_SHIFT2 ___ 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
