[Xen-ia64-devel] [PATCH] [RESEND] Changed from page_info to page
Hi, We thought that there might be the comment that you should have unified to page_info, but it was our unnecessary worry. Because this patch did not have comment, please apply this patch. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan, and Fujitsu team page_info2page.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] [RESEND] Changed from page_info to page
From: Masaki Kanno Sent: 2006年3月16日 16:32 Hi, We thought that there might be the comment that you should have unified to page_info, but it was our unnecessary worry. Because this patch did not have comment, please apply this patch. Yes, here comes comment. :-) A naming choice here: - define structure page_info in mm.h, and define page as a macro to page_info, which sticks to xen's convention since all other places (common, x86 specific, etc) are referred by page_info - Or define structure page in mm.h, as what you're approaching, which towards linux style since we have still a set of linux files copied there Yes, nothing differed in final binary, however to me it's more natural for first option, since gradually we'll remove all unnecessary linux stuff. Patch to remove using page may be more welcomed instead... Thanks, Kevin Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan, and Fujitsu team ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[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) 永康 Kernel command line: root=/dev/hda1 ro nomca nosmp xencons=tty0 console=tty0 ro ot=/dev/hda1 3 PID hash table entries: 1024 (order: 10, 32768 bytes) xen_pal_emulator: index=14 (XEN) Running on Xen! start_info_pfn=0x3ffd nr_pages=16384 flags=0x0 xen-event-channel using irq 233 vcpu_translate: bad physical address: 0xa001a090 (XEN) translate_domain_pte: bad mpa=0x1a090 ( 0x1000),vadr=0xa00100 00a090,pteval=0x11a761,itir=0x38 (XEN) lookup_domain_mpa: bad mpa 0x1a090 ( 0x1000) (XEN) vcpu_translate: bad physical address: 0xbf200010 (XEN) translate_domain_pte: bad mpa=0x3ff200010 ( 0x1000),vadr=0xbf 200010,pteval=0x13ff200761,itir=0x38 (XEN) lookup_domain_mpa: bad mpa 0x3ff200010 ( 0x1000) (XEN) translate_domain_pte: bad mpa=0xff54f000e090 ( 0x1000),vadr=0xa00 1a090,pteval=0xf000ff54f000eef3,itir=0x538 (XEN) lookup_domain_mpa: bad mpa 0xff54f000e090 ( 0x1000) (XEN) ia64_fault: General Exception: IA-64 Reserved Register/Field fault (data a ccess): reflecting (XEN) $ PANIC in domain 2 (k6=0xf7fc8000): psr.ic off, delivering fa ult=5400,ipsr=121008226018,iip=f4042f20,ifa=a001a090,isr=000 000800030,PSCB.iip (XEN) CPU 1 (XEN) psr : 121008226018 ifs : 858f ip : [f4042f21] (XEN) ip is at printf+0x441/0x580 (XEN) unat: pfs : 0510 rsc : 0003 (XEN) rnat: 0009804c8a70033f bsps: f40fefb9 pr : 0555a9a9 (XEN) ldrs: ccv : fpsr: 0009804c8a70033f (XEN) csd : ssd : (XEN) b0 : f406d4d0 b6 : f4044c00 b7 : (XEN) f6 : 0fffaf000 f7 : 0ffdb8000 (XEN) f8 : 08000 f9 : 100038000 (XEN) f10 : 0fffaf000 f11 : 1003e (XEN) r1 : f42f2380 r2 : 3d81 r3 : f7fcffe8 (XEN) r8 : fff3 r9 : r10 : (XEN) r11 : 0009804c0270033f r12 : f7fcfde0 r13 : f7fc8000 (XEN) r14 : f7ffa1b8 r15 : 001008226018 r16 : f40f4590 (XEN) r17 : f7fc8010 r18 : fd81 r19 : f40f45f8 (XEN) r20 : 0e17 r21 : r22 : 7f01ffe8 (XEN) r23 : 0e17 r24 : f7fcfe20 r25 : f7fcfe28 (XEN) r26 : r27 : r28 : (XEN) r29 : a001a070 r30 : r31 : f40ff4d0 (XEN) (XEN) Call Trace: (XEN) [f4096c10] show_stack+0xa0/0xc0 (XEN) sp=f7fcf8e0 bsp=f7fc9200 (XEN) [f4053150] panic_domain+0x280/0x330 (XEN) sp=f7fcfab0 bsp=f7fc9170 (XEN) [f404df70] check_bad_nested_interruption+0x140/0x160 (XEN) sp=f7fcfb60 bsp=f7fc9138 (XEN) [f404e200] reflect_interruption+0x270/0x480 (XEN) sp=f7fcfb60 bsp=f7fc90e8 (XEN) [f404ede0] ia64_fault+0x170/0x520 (XEN) sp=f7fcfb60 bsp=f7fc90a0 (XEN) [f4061e00] ia64_leave_kernel+0x0/0x310 (XEN) sp=f7fcfbe0 bsp=f7fc90a0 (XEN) [f4042f20] printf+0x440/0x580 (XEN) sp=f7fcfde0 bsp=f7fc9028 (XEN) BUG at domain.c:341 (XEN) bad hyperprivop; ignored (XEN) iim=0, iip=0xf4020730 (XEN) bad hyperprivop; ignored (XEN) iim=0, iip=0xf402073 ... (XEN) bad hyperprivop; ignored (XEN) iim=0, iip=0xf4020730 (XEN) bad hyperprivop; ignored (XEN) iim=0, iip=0xf4020730 (XEN) bad hype(XEN) iim=0, iip=0xf4020730 (XEN) bad hyperprivop; ignored (XEN) iim=0, iip=0xf4020730 (XEN) bad hyperprivop; ignored ...___ 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
Le Jeudi 16 Mars 2006 10:19, You, Yongkang a écrit : 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. Hi, this is a very good catch. I hope you can easily reproduce this bug, but I can't. I suppose this is due to configuration. Are you using RHEL4u2 ? How have you installed Xen ? How have you build the disk image ? Thanks, Tristan. ___ 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
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
RE: [Xen-ia64-devel] Create 2nd XenU fail after destroy 1st one
-Original Message- From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年3月16日 17:33 To: You, Yongkang; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] Create 2nd XenU fail after destroy 1st one Le Jeudi 16 Mars 2006 10:19, You, Yongkang a écrit : 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. Hi, this is a very good catch. I hope you can easily reproduce this bug, but I can't. Meet this issue every time. Could you give more information about your steps about creating and destroying? :) I suppose this is due to configuration. Are you using RHEL4u2 ? Yes. How have you installed Xen ? I make the rpm and install it. It just like make install that copying xen files to destination. How have you build the disk image ? I am not sure how the disk image is related to this issue. I use an image file. That image is usable for every 1st times creating. Actually I also try to keep VTI and XenU alive at the same time (not run create at the same time.), after destroy XenU the whole system also hang. I paste my XenU config file here. ==xenU config== kernel = /boot/vmlinux-xenU memory = 256 name = rhel4u2xenU disk = [ 'file:/data/xenu_disk_image/domU.img,hda1,w' ] root = /dev/hda1 ro extra = nomca nosmp xencons=tty0 console=tty0 root=/dev/hda1 3 == Thanks, Tristan. 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] 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] Create 2nd XenU fail after destroy 1st one
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年3月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
Re: [Xen-ia64-devel] Create 2nd XenU fail after destroy 1st one
Le Jeudi 16 Mars 2006 10:48, You, Yongkang a écrit : -Original Message- From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年3月16日 17:33 To: You, Yongkang; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] Create 2nd XenU fail after destroy 1st one Le Jeudi 16 Mars 2006 10:19, You, Yongkang a écrit : 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. Hi, this is a very good catch. I hope you can easily reproduce this bug, but I can't. Meet this issue every time. Could you give more information about your steps about creating and destroying? :) I don't use RHEL4 usually. I will install it. Thank you for the details. Tristan. ___ 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
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ト\xF3ヤツ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
Re: [Xen-ia64-devel] [PATCH] [RESEND] Changed from page_info to page
Hi, We agree first option. But we think that we change it slowly because there are many change points. We think that the following are change steps. 1. Change from page to page_info in xen/arch/ia64/xen/*.c and xen/include/asm-ia64/*.h. 2. Remove unnecessary page in xen/arch/linux-xen/*.c, xen/include/asm-ia64/linux-xen/*.h and xen/include/asm-ia64/linux/*.h. 3. Remove #define page_info page in xen/include/asm-ia64/config.h. Best regards, Kan and Akio Tian, Kevin wrote: From: Masaki Kanno Sent: 2006定3埖16晩 16:32 Hi, We thought that there might be the comment that you should have unified to page_info, but it was our unnecessary worry. Because this patch did not have comment, please apply this patch. Yes, here comes comment. :-) A naming choice here: - define structure page_info in mm.h, and define page as a macro to page_info, which sticks to xen's convention since all other places (common, x86 specific, etc) are referred by page_info - Or define structure page in mm.h, as what you're approaching, which towards linux style since we have still a set of linux files copied there Yes, nothing differed in final binary, however to me it's more natural for first option, since gradually we'll remove all unnecessary linux stuff. Patch to remove using page may be more welcomed instead... Thanks, Kevin Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan, and Fujitsu team ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] LTP case nanosleep02 failed in Xen0
Le Jeudi 16 Mars 2006 09:47, You, Yongkang a écrit : Hi all, I have updated LTP to latest 20060306. After running it, I found there were several failed cases in recent xen-ia64-unstable source. I will report them in sequence. I run the latest LTP on Cset 9267 on Tiger 4 Itanium 2. Nanosleep02 is one of system call case. This case is interesting, sometime it is pass, sometime is fail. So maybe there are something wrong with the timer of Xen0? [EMAIL PROTECTED] bin]# ./nanosleep02 nanosleep021 FAIL : Remaining sleep time 3998 msec doesn't match with the expected 3999 msec time nanosleep021 FAIL : child process exited abnormally I don't think there is something wrong. I suppose dom0 may look slow or hanged. I suppose this test could also fail on ia64 if an interrupt arrives at the 'good' time. According to the error message, the test is not that wrong. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]: use of max_addr= command line
Hi,
Use 'max_addr' option to limit the amount of physical memory. The default
is 4G (the same as the previous hard limit). The hard-coded limit is removed.
dom0_command_line now contains the cmdline for dom0 linux.
saved_command_line now contains the cmdline for Xen (it is used in Xen).
Tested by boot+shutdown of dom0+2*domU.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 7ba68c5d1169c530f8863c244e8f0256f579b9d6
# Parent ab05373d6edde3ddebb87eb587d1608db6901ecf
Use 'max_addr' option to limit the amount of physical memory. The default
is 4G (the same as the previous hard limit). The hard-coded limit is removed.
dom0_command_line now contains the cmdline for dom0 linux.
saved_command_line now contains the cmdline for Xen (it is used in Xen).
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r ab05373d6edd -r 7ba68c5d1169 xen/arch/ia64/linux-xen/efi.c
--- a/xen/arch/ia64/linux-xen/efi.c Wed Mar 15 15:33:23 2006
+++ b/xen/arch/ia64/linux-xen/efi.c Thu Mar 16 08:32:08 2006
@@ -42,7 +42,12 @@
struct efi efi;
EXPORT_SYMBOL(efi);
static efi_runtime_services_t *runtime;
+#ifdef XEN
+// this is a temporary hack to avoid CONFIG_VIRTUAL_MEM_MAP
+static unsigned long mem_limit = ~0UL, max_addr = 0x1;
+#else
static unsigned long mem_limit = ~0UL, max_addr = ~0UL;
+#endif
#define efi_call_virt(f, args...) (*(f))(args)
@@ -329,8 +334,6 @@
if (running_on_sim md-type != EFI_CONVENTIONAL_MEMORY)
continue;
}
-// this is a temporary hack to avoid CONFIG_VIRTUAL_MEM_MAP
- if (md-phys_addr = 0x1) continue;
#endif
/*
* granule_addr is the base of md's first granule.
diff -r ab05373d6edd -r 7ba68c5d1169 xen/arch/ia64/linux-xen/setup.c
--- a/xen/arch/ia64/linux-xen/setup.c Wed Mar 15 15:33:23 2006
+++ b/xen/arch/ia64/linux-xen/setup.c Thu Mar 16 08:32:08 2006
@@ -384,6 +384,9 @@
*cmdline_p = __va(ia64_boot_param-command_line);
#ifndef XEN
strlcpy(saved_command_line, *cmdline_p, COMMAND_LINE_SIZE);
+#else
+ early_cmdline_parse(cmdline_p);
+ cmdline_parse(*cmdline_p);
#endif
efi_init();
@@ -414,10 +417,6 @@
}
#endif
-#ifdef XEN
- early_cmdline_parse(cmdline_p);
- cmdline_parse(*cmdline_p);
-#endif
if (early_console_setup(*cmdline_p) == 0)
mark_bsp_online();
diff -r ab05373d6edd -r 7ba68c5d1169 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.c Wed Mar 15 15:33:23 2006
+++ b/xen/arch/ia64/xen/domain.c Thu Mar 16 08:32:08 2006
@@ -26,6 +26,7 @@
#include asm/processor.h
#include asm/desc.h
#include asm/hw_irq.h
+#include asm/setup.h
//#include asm/mpspec.h
#include xen/irq.h
#include xen/event.h
@@ -36,7 +37,6 @@
#include xen/elf.h
//#include asm/page.h
#include asm/pgalloc.h
-#include asm/dma.h /* for MAX_DMA_ADDRESS */
#include asm/asm-offsets.h /* for IA64_THREAD_INFO_SIZE */
@@ -49,6 +49,7 @@
#include asm/pal.h
#include asm/vhpt.h
#include public/hvm/ioreq.h
+#include public/arch-ia64.h
#include asm/tlbflush.h
#include asm/regionreg.h
@@ -415,7 +416,7 @@
{
struct domain *d = v-domain;
struct pt_regs *regs;
- extern char saved_command_line[];
+ extern char dom0_command_line[];
#ifdef CONFIG_DOMAIN0_CONTIGUOUS
if (d == dom0) start_pc += dom0_start;
@@ -439,24 +440,27 @@
if (VMX_DOMAIN(v)) {
vmx_init_all_rr(v);
if (d == dom0)
-// VCPU(v,vgr[12]) = dom_fw_setup(d,saved_command_line,256L);
- regs-r28 = dom_fw_setup(d,saved_command_line,256L);
+ regs-r28 = dom_fw_setup(d,dom0_command_line,
+ COMMAND_LINE_SIZE);
/* Virtual processor context setup */
VCPU(v, vpsr) = IA64_PSR_BN;
VCPU(v, dcr) = 0;
} else {
init_all_rr(v);
if (d == dom0)
- regs-r28 = dom_fw_setup(d,saved_command_line,256L);
+ regs-r28 = dom_fw_setup(d,dom0_command_line,
+ COMMAND_LINE_SIZE);
else {
regs-ar_rsc |= (2 2); /* force PL2/3 */
if (*d-arch.cmdline == '\0') {
#define DEFAULT_CMDLINE nomca nosmp xencons=tty0 console=tty0 root=/dev/hda1
- regs-r28 = dom_fw_setup(d,DEFAULT_CMDLINE,256L);
+ regs-r28 = dom_fw_setup(d,DEFAULT_CMDLINE,
+ sizeof (DEFAULT_CMDLINE));
printf(domU command line defaulted to
DEFAULT_CMDLINE \n);
}
- else regs-r28 = dom_fw_setup(d,d-arch.cmdline,256L);
+ else regs-r28 = dom_fw_setup(d,d-arch.cmdline,
+ IA64_COMMAND_LINE_SIZE);
}
VCPU(v, banknum) = 1;
VCPU(v, metaphysical_mode) = 1;
@@ -645,12 +649,13 @@
#ifdef CONFIG_DOMAIN0_CONTIGUOUS
if (d == dom0) {
+ pte_t pteval;
if (mpaddr dom0_start || mpaddr = dom0_start + dom0_size) {
//printk(lookup_domain_mpa: bad dom0 mpaddr 0x%lx!\n,mpaddr);
//printk(lookup_domain_mpa: start=0x%lx,end=0x%lx!\n,dom0_start,dom0_start+dom0_size);
mpafoo(mpaddr);
}
- pte_t pteval = pfn_pte(mpaddr PAGE_SHIFT,
+ pteval = pfn_pte(mpaddr PAGE_SHIFT,
__pgprot(__DIRTY_BITS | _PAGE_PL_2 | _PAGE_AR_RWX));
pte = pteval;
return *(unsigned long *)pte;
diff -r ab05373d6edd -r 7ba68c5d1169 xen/arch/ia64/xen/xensetup.c
---
[Xen-ia64-devel] [PATCH] Step1 : Changed from page to page_info
Hi, This patch changed from struct page to struct page_info in the below files. - xen/arch/ia64/xen/domain.c - xen/arch/ia64/xen/mm_init.c - xen/arch/ia64/xen/xenmem.c - xen/arch/ia64/xen/xenmisc.c - xen/include/asm-ia64/config.h - xen/include/asm-ia64/mm.h This patch is step1 which we showed by the following mail. http://lists.xensource.com/archives/html/xen-ia64-devel/2006-03/msg00305.html Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan and Akio page2page_info.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]: new hyperprivop
Hi,
following previous discussion, here is an implementation of missings
hyperprivops.
Tested by booting and using a modified linux.
Tristan.# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 2f268ff345e520fa06873a1dfe65352f262c1257
# Parent 0b87b472cd3324536fa4bb05917bc2fd7c2e02c3
Missing hyperprivop added.
These were privified insn without hyperprivop.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 0b87b472cd33 -r 2f268ff345e5 xen/arch/ia64/xen/privop.c
--- a/xen/arch/ia64/xen/privop.c Thu Mar 16 11:14:49 2006
+++ b/xen/arch/ia64/xen/privop.c Thu Mar 16 11:20:41 2006
@@ -797,12 +797,17 @@
#define HYPERPRIVOP_GET_RR 0x10
#define HYPERPRIVOP_SET_RR 0x11
#define HYPERPRIVOP_SET_KR 0x12
-#define HYPERPRIVOP_MAX 0x12
+#define HYPERPRIVOP_FC 0x13
+#define HYPERPRIVOP_GET_CPUID 0x14
+#define HYPERPRIVOP_GET_PMD 0x15
+#define HYPERPRIVOP_GET_EFLAG 0x16
+#define HYPERPRIVOP_SET_EFLAG 0x17
+#define HYPERPRIVOP_MAX 0x17
static const char * const hyperpriv_str[HYPERPRIVOP_MAX+1] = {
0, rfi, rsm.dt, ssm.dt, cover, itc.d, itc.i, ssm.i,
=ivr, =tpr, tpr=, eoi, itm=, thash, ptc.ga, itr.d,
- =rr, rr=, kr=
+ =rr, rr=, kr=, fc, =cpuid, =pmd, =ar.eflg, ar.eflg=
};
unsigned long slow_hyperpriv_cnt[HYPERPRIVOP_MAX+1] = { 0 };
@@ -888,6 +893,24 @@
return 1;
case HYPERPRIVOP_SET_KR:
(void)vcpu_set_ar(v,regs-r8,regs-r9);
+ return 1;
+ case HYPERPRIVOP_FC:
+ (void)vcpu_fc(v,regs-r8);
+ return 1;
+ case HYPERPRIVOP_GET_CPUID:
+ (void)vcpu_get_cpuid(v,regs-r8,val);
+ regs-r8 = val;
+ return 1;
+ case HYPERPRIVOP_GET_PMD:
+ (void)vcpu_get_pmd(v,regs-r8,val);
+ regs-r8 = val;
+ return 1;
+ case HYPERPRIVOP_GET_EFLAG:
+ (void)vcpu_get_ar(v,24,val);
+ regs-r8 = val;
+ return 1;
+ case HYPERPRIVOP_SET_EFLAG:
+ (void)vcpu_set_ar(v,24,regs-r8);
return 1;
}
return 0;
@@ -934,7 +957,7 @@
};
// FIXME: should use snprintf to ensure no buffer overflow
-int dump_privop_counts(char *buf)
+static int dump_privop_counts(char *buf)
{
int i, j;
UINT64 sum = 0;
@@ -1007,7 +1030,7 @@
return s - buf;
}
-int zero_privop_counts(char *buf)
+static int zero_privop_counts(char *buf)
{
int i, j;
char *s = buf;
@@ -1043,7 +1066,7 @@
v-overflow++;;
}
-int dump_privop_addrs(char *buf)
+static int dump_privop_addrs(char *buf)
{
int i,j;
char *s = buf;
@@ -1061,7 +1084,7 @@
return s - buf;
}
-void zero_privop_addrs(void)
+static void zero_privop_addrs(void)
{
int i,j;
for (i = 0; i PRIVOP_COUNT_NINSTS; i++) {
@@ -1085,7 +1108,7 @@
extern unsigned long pal_halt_light_count;
extern unsigned long context_switch_count;
-int dump_misc_stats(char *buf)
+static int dump_misc_stats(char *buf)
{
char *s = buf;
s += sprintf(s,Virtual TR translations: %ld\n,tr_translate_count);
@@ -1102,7 +1125,7 @@
return s - buf;
}
-void zero_misc_stats(void)
+static void zero_misc_stats(void)
{
dtlb_translate_count = 0;
tr_translate_count = 0;
@@ -1117,7 +1140,7 @@
context_switch_count = 0;
}
-int dump_hyperprivop_counts(char *buf)
+static int dump_hyperprivop_counts(char *buf)
{
int i;
char *s = buf;
@@ -1138,7 +1161,7 @@
return s - buf;
}
-void zero_hyperprivop_counts(void)
+static void zero_hyperprivop_counts(void)
{
int i;
for (i = 0; i = HYPERPRIVOP_MAX; i++) slow_hyperpriv_cnt[i] = 0;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]: remaining privified insns removed
Hi, this patch removes all the remaining privified insns in the linux kernel. Tested by boot+shutdown of dom0+2*domU and reading stats with postat. Tristan. # HG changeset patch # User [EMAIL PROTECTED] # Node ID 803d3b97f05da42569a7993e23824e058b6a9505 # Parent 2f268ff345e520fa06873a1dfe65352f262c1257 Privified insns replaced by hyperprivops. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r 2f268ff345e5 -r 803d3b97f05d linux-2.6-xen-sparse/arch/ia64/xen/hypercall.S --- a/linux-2.6-xen-sparse/arch/ia64/xen/hypercall.S Thu Mar 16 11:20:41 2006 +++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypercall.S Thu Mar 16 11:49:52 2006 @@ -254,7 +254,6 @@ st8 [r11]=r10 ;; br.ret.sptk.many rp - ;; END(xen_set_rr) GLOBAL_ENTRY(xen_fc) @@ -264,7 +263,16 @@ (p7) fc r32;; (p7) br.ret.sptk.many rp ;; - ptc.e r96 // this is a privified fc r32 + movl r9=XSI_PSR_IC + mov r8=r32 + ;; + ld8 r10=[r9] + ;; + st8 [r9]=r0 + ;; + XEN_HYPER_FC + ;; + st8 [r9]=r10 ;; br.ret.sptk.many rp END(xen_fc) @@ -276,7 +284,16 @@ (p7) mov r8=cpuid[r32];; (p7) br.ret.sptk.many rp ;; - mov r72=rr[r32] // this is a privified mov r8=cpuid[r32] + movl r9=XSI_PSR_IC + mov r8=r32 + ;; + ld8 r10=[r9] + ;; + st8 [r9]=r0 + ;; + XEN_HYPER_GET_CPUID + ;; + st8 [r9]=r10 ;; br.ret.sptk.many rp END(xen_get_cpuid) @@ -288,7 +305,16 @@ (p7) mov r8=pmd[r32];; (p7) br.ret.sptk.many rp ;; - mov r72=pmc[r32] // this is a privified mov r8=pmd[r32] + movl r9=XSI_PSR_IC + mov r8=r32 + ;; + ld8 r10=[r9] + ;; + st8 [r9]=r0 + ;; + XEN_HYPER_GET_PMD + ;; + st8 [r9]=r10 ;; br.ret.sptk.many rp END(xen_get_pmd) @@ -301,10 +327,20 @@ (p7) mov r8=ar24;; (p7) br.ret.sptk.many rp ;; - mov ar24=r72 // this is a privified mov r8=ar.eflg + movl r9=XSI_PSR_IC + mov r8=r32 + ;; + ld8 r10=[r9] + ;; + st8 [r9]=r0 + ;; + XEN_HYPER_GET_EFLAG + ;; + st8 [r9]=r10 ;; br.ret.sptk.many rp END(xen_get_eflag) + // some bits aren't set if pl!=0, see SDM vol1 3.1.8 GLOBAL_ENTRY(xen_set_eflag) movl r8=running_on_xen;; @@ -313,11 +349,17 @@ (p7) mov ar24=r32 (p7) br.ret.sptk.many rp ;; - // FIXME: this remains no-op'd because it generates - // a privileged register (general exception) trap rather than - // a privileged operation fault - //mov ar24=r32 - ;; - br.ret.sptk.many rp -END(xen_get_eflag) + movl r9=XSI_PSR_IC + mov r8=r32 + ;; + ld8 r10=[r9] + ;; + st8 [r9]=r0 + ;; + XEN_HYPER_SET_EFLAG + ;; + st8 [r9]=r10 + ;; + br.ret.sptk.many rp +END(xen_set_eflag) #endif diff -r 2f268ff345e5 -r 803d3b97f05d linux-2.6-xen-sparse/arch/ia64/xen/xenivt.S --- a/linux-2.6-xen-sparse/arch/ia64/xen/xenivt.S Thu Mar 16 11:20:41 2006 +++ b/linux-2.6-xen-sparse/arch/ia64/xen/xenivt.S Thu Mar 16 11:49:52 2006 @@ -723,16 +723,12 @@ movl r30=1f// load continuation point in case of nested fault ;; #ifdef CONFIG_XEN -#if 1 mov r18=r8; mov r8=r16; XEN_HYPER_THASH;; mov r17=r8; mov r8=r18;; #else - tak r17=r80// privified thash -#endif -#else thash r17=r16// compute virtual address of L3 PTE #endif mov r29=b0// save b0 in case of nested fault @@ -812,16 +808,12 @@ #endif /* CONFIG_ITANIUM */ ;; #ifdef CONFIG_XEN -#if 1 mov r18=r8; mov r8=r16; XEN_HYPER_THASH;; mov r17=r8; mov r8=r18;; #else - tak r17=r80// privified thash -#endif -#else thash r17=r16// compute virtual address of L3 PTE #endif mov r29=b0// save b0 in case of nested fault) @@ -898,15 +890,11 @@ movl r30=1f// load continuation point in case of nested fault ;; #ifdef CONFIG_XEN -#if 1 mov r18=r8; mov r8=r16; XEN_HYPER_THASH;; mov r17=r8; mov r8=r18;; -#else - tak r17=r80// privified thash -#endif #else thash r17=r16// compute virtual address of L3 PTE #endif diff -r 2f268ff345e5 -r 803d3b97f05d linux-2.6-xen-sparse/include/asm-ia64/xen/privop.h --- a/linux-2.6-xen-sparse/include/asm-ia64/xen/privop.h Thu Mar 16 11:20:41 2006 +++ b/linux-2.6-xen-sparse/include/asm-ia64/xen/privop.h Thu Mar 16 11:49:52 2006 @@ -33,6 +33,11 @@ #define XEN_HYPER_GET_RR break 0x10 #define XEN_HYPER_SET_RR break 0x11 #define XEN_HYPER_SET_KR break 0x12 +#define XEN_HYPER_FC break 0x13 +#define XEN_HYPER_GET_CPUID break 0x14 +#define XEN_HYPER_GET_PMD break 0x15 +#define XEN_HYPER_GET_EFLAG break 0x16 +#define XEN_HYPER_SET_EFLAG break 0x17 #endif #ifndef __ASSEMBLY__ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]: disable handling of legacy privified insns
Hi,
this patch conditionnaly disable privified insns into another insn.
Be sure to use an updated linux kernel before running with this xen!
Tested by boot+shutdown of dom0+2*domU
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID e514590977006bca331eb4470b09b96172ad83ea
# Parent 803d3b97f05da42569a7993e23824e058b6a9505
Disable handling of privified insns into another instructions.
This is controled by a static constant.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 803d3b97f05d -r e51459097700 xen/arch/ia64/xen/privop.c
--- a/xen/arch/ia64/xen/privop.c Thu Mar 16 11:49:52 2006
+++ b/xen/arch/ia64/xen/privop.c Thu Mar 16 12:16:28 2006
@@ -19,6 +19,9 @@
extern void zero_reflect_counts(void);
long priv_verbose=0;
+
+/* Set to 1 to handle privified instructions from the privify tool. */
+static const int privify_en = 0;
/**
Hypercall bundle creation
@@ -131,7 +134,8 @@
UINT src = inst.M28.r3;
// NOTE: ptc_e with source gr 63 is emulated as a fc r(y-64)
- if (src 63) return(vcpu_fc(vcpu,vcpu_get_gr(vcpu,src - 64)));
+ if (privify_en src 63)
+ return(vcpu_fc(vcpu,vcpu_get_gr(vcpu,src - 64)));
return vcpu_ptc_e(vcpu,vcpu_get_gr(vcpu,src));
}
@@ -178,7 +182,7 @@
UINT src = inst.M46.r3;
// NOTE: tpa with source gr 63 is emulated as a ttag rx=r(y-64)
- if (src 63)
+ if (privify_en src 63)
fault = vcpu_ttag(vcpu,vcpu_get_gr(vcpu,src-64),padr);
else fault = vcpu_tpa(vcpu,vcpu_get_gr(vcpu,src),padr);
if (fault == IA64_NO_FAULT)
@@ -193,7 +197,7 @@
UINT src = inst.M46.r3;
// NOTE: tak with source gr 63 is emulated as a thash rx=r(y-64)
- if (src 63)
+ if (privify_en src 63)
fault = vcpu_thash(vcpu,vcpu_get_gr(vcpu,src-64),key);
else fault = vcpu_tak(vcpu,vcpu_get_gr(vcpu,src),key);
if (fault == IA64_NO_FAULT)
@@ -280,7 +284,8 @@
// I26 and M29 are identical for these fields
UINT64 ar3 = inst.M29.ar3;
- if (inst.M29.r2 63 inst.M29.ar3 8) { // privified mov from kr
+ if (privify_en inst.M29.r2 63 inst.M29.ar3 8) {
+ // privified mov from kr
UINT64 val;
if (vcpu_get_ar(vcpu,ar3,val) != IA64_ILLOP_FAULT)
return vcpu_set_gr(vcpu, inst.M29.r2-64, val,0);
@@ -404,14 +409,17 @@
{
UINT64 val;
IA64FAULT fault;
+ int reg;
- if (inst.M43.r1 63) { // privified mov from cpuid
- fault = vcpu_get_cpuid(vcpu,vcpu_get_gr(vcpu,inst.M43.r3),val);
+ reg = vcpu_get_gr(vcpu,inst.M43.r3);
+ if (privify_en inst.M43.r1 63) {
+ // privified mov from cpuid
+ fault = vcpu_get_cpuid(vcpu,reg,val);
if (fault == IA64_NO_FAULT)
return vcpu_set_gr(vcpu, inst.M43.r1-64, val, 0);
}
else {
- fault = vcpu_get_rr(vcpu,vcpu_get_gr(vcpu,inst.M43.r3),val);
+ fault = vcpu_get_rr(vcpu,reg,val);
if (fault == IA64_NO_FAULT)
return vcpu_set_gr(vcpu, inst.M43.r1, val, 0);
}
@@ -455,14 +463,17 @@
{
UINT64 val;
IA64FAULT fault;
+ int reg;
- if (inst.M43.r1 63) { // privified mov from pmd
- fault = vcpu_get_pmd(vcpu,vcpu_get_gr(vcpu,inst.M43.r3),val);
+ reg = vcpu_get_gr(vcpu,inst.M43.r3);
+ if (privify_en inst.M43.r1 63) {
+ // privified mov from pmd
+ fault = vcpu_get_pmd(vcpu,reg,val);
if (fault == IA64_NO_FAULT)
return vcpu_set_gr(vcpu, inst.M43.r1-64, val, 0);
}
else {
- fault = vcpu_get_pmc(vcpu,vcpu_get_gr(vcpu,inst.M43.r3),val);
+ fault = vcpu_get_pmc(vcpu,reg,val);
if (fault == IA64_NO_FAULT)
return vcpu_set_gr(vcpu, inst.M43.r1, val, 0);
}
@@ -666,7 +677,7 @@
else if (inst.generic.major != 1) break;
x6 = inst.M29.x6;
if (x6 == 0x2a) {
- if (inst.M29.r2 63 inst.M29.ar3 8)
+ if (privify_en inst.M29.r2 63 inst.M29.ar3 8)
privcnt.mov_from_ar++; // privified mov from kr
else privcnt.mov_to_ar_reg++;
return priv_mov_to_ar_reg(vcpu,inst);
@@ -674,14 +685,14 @@
if (inst.M29.x3 != 0) break;
if (!(pfunc = Mpriv_funcs[x6])) break;
if (x6 == 0x1e || x6 == 0x1f) { // tpa or tak are special
- if (inst.M46.r3 63) {
+ if (privify_en inst.M46.r3 63) {
if (x6 == 0x1e) x6 = 0x1b;
else x6 = 0x1a;
}
}
- if (x6 == 52 inst.M28.r3 63)
+ if (privify_en x6 == 52 inst.M28.r3 63)
privcnt.fc++;
- else if (x6 == 16 inst.M43.r3 63)
+ else if (privify_en x6 == 16 inst.M43.r3 63)
privcnt.cpuid++;
else privcnt.Mpriv_cnt[x6]++;
return (*pfunc)(vcpu,inst);
@@ -718,7 +729,7 @@
#endif
if (inst.I26.x3 != 0) break; // I26.x3 == I27.x3
if (inst.I26.x6 == 0x2a) {
- if (inst.I26.r2 63 inst.I26.ar3 8)
+ if (privify_en inst.I26.r2 63 inst.I26.ar3 8)
privcnt.mov_from_ar++; // privified mov from kr
else privcnt.mov_to_ar_reg++;
return priv_mov_to_ar_reg(vcpu,inst);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] fix AFLAGS in Rules.mk
On Thu, 2006-03-16 at 09:36 +0900, Akio Takebe wrote: diff -r 911c04274f14 xen/arch/ia64/Rules.mk --- a/xen/arch/ia64/Rules.mkTue Mar 14 14:38:22 2006 -0700 +++ b/xen/arch/ia64/Rules.mkThu Mar 16 09:07:33 2006 +0900 @@ -5,7 +5,7 @@ ifneq ($(COMPILE_ARCH),$(TARGET_ARCH)) ifneq ($(COMPILE_ARCH),$(TARGET_ARCH)) CROSS_COMPILE ?= /usr/local/sp_env/v2.2.5/i686/bin/ia64-unknown-linux- endif -AFLAGS += -D__ASSEMBLY__ +AFLAGS += -D__ASSEMBLY__ -nostdinc $(CPPFLAGS) CPPFLAGS += -I$(BASEDIR)/include -I$(BASEDIR)/include/asm-ia64\ -I$(BASEDIR)/include/asm-ia64/linux \ -I$(BASEDIR)/include/asm-ia64/linux-xen\ Applied. Please be careful cutting-and-pasting patches into email, it's easy to get tabs converted to spaces w/o noticing. 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
Re: [Xen-ia64-devel] [PATCH] Step1 : Changed from page to page_info
On Thu, 2006-03-16 at 22:44 +0900, Masaki Kanno wrote: Hi, This patch changed from struct page to struct page_info in the below files. - xen/arch/ia64/xen/domain.c - xen/arch/ia64/xen/mm_init.c - xen/arch/ia64/xen/xenmem.c - xen/arch/ia64/xen/xenmisc.c - xen/include/asm-ia64/config.h - xen/include/asm-ia64/mm.h This patch is step1 which we showed by the following mail. Applied. -- 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] Re: [PATCH]: postat tool
On Thu, 2006-03-16 at 16:08 +0100, Tristan Gingold wrote: Hi, I am sure that such a tool already exist somewhere, but I didn't find it in the Xen repository. postat displays/clears privop statistics. Applied. -- 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] Re: [PATCH]: new hyperprivop
On Thu, 2006-03-16 at 16:14 +0100, Tristan Gingold wrote: Hi, following previous discussion, here is an implementation of missings hyperprivops. Applied. -- 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] Re: [PATCH]: remaining privified insns removed
On Thu, 2006-03-16 at 16:43 +0100, Tristan Gingold wrote: Hi, this patch removes all the remaining privified insns in the linux kernel. Applied. -- 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] Re: [PATCH]: disable handling of legacy privified insns
On Thu, 2006-03-16 at 17:11 +0100, Tristan Gingold wrote: Hi, this patch conditionnaly disable privified insns into another insn. Be sure to use an updated linux kernel before running with this xen! Applied. -- 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] update linux kernels w/ xen-ia64 cset 9275
Please note, xen-ia64 cset 9275 will break functionality if a new xen images is used with an old xenlinux kernel. Please be sure to update your xenlinux image. 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
RE: [Xen-ia64-devel] [PATCH] [RESEND] Changed from page_info to page
From: Masaki Kanno [mailto:[EMAIL PROTECTED] Sent: 2006年3月16日 19:14 Hi, We agree first option. But we think that we change it slowly because there are many change points. We think that the following are change steps. 1. Change from page to page_info in xen/arch/ia64/xen/*.c and xen/include/asm-ia64/*.h. 2. Remove unnecessary page in xen/arch/linux-xen/*.c, xen/include/asm-ia64/linux-xen/*.h and xen/include/asm-ia64/linux/*.h. 3. Remove #define page_info page in xen/include/asm-ia64/config.h. Best regards, Kan and Akio Sure. Thanks, Kevin Tian, Kevin wrote: From: Masaki Kanno Sent: 2006定3��16�� 16:32 Hi, We thought that there might be the comment that you should have unified to page_info, but it was our unnecessary worry. Because this patch did not have comment, please apply this patch. Yes, here comes comment. :-) A naming choice here: - define structure page_info in mm.h, and define page as a macro to page_info, which sticks to xen's convention since all other places (common, x86 specific, etc) are referred by page_info - Or define structure page in mm.h, as what you're approaching, which towards linux style since we have still a set of linux files copied there Yes, nothing differed in final binary, however to me it's more natural for first option, since gradually we'll remove all unnecessary linux stuff. Patch to remove using page may be more welcomed instead... Thanks, Kevin Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan, and Fujitsu team ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275
Hi Alex, I am not very clear about the new Xen image and the old xenlinux kernel standard for. Does xenlinux kernel mean xenU kernel? Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006年3月17日 4:29 To: xen-ia64-devel Subject: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275 Please note, xen-ia64 cset 9275 will break functionality if a new xen images is used with an old xenlinux kernel. Please be sure to update your xenlinux image. 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 mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Re: [PATCH]: disable handling of legacy privifiedinsns
Legacy privifiedinsns is being used; please turn on it by default. Thanks, -Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006年3月17日 4:26 To: Tristan Gingold Cc: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] Re: [PATCH]: disable handling of legacy privifiedinsns On Thu, 2006-03-16 at 17:11 +0100, Tristan Gingold wrote: Hi, this patch conditionnaly disable privified insns into another insn. Be sure to use an updated linux kernel before running with this xen! Applied. -- 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 mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Step2 : Remove header files where page is used
Hi, This patch removed the following header files where struct page was used. - xen/include/asm-ia64/linux/asm-generic/pci-dma-compat.h - xen/include/asm-ia64/linux/asm/scatterlist.h - xen/include/asm-ia64/linux/rbtree.h - xen/include/asm-ia64/linux/page-flags.h Please create the following header files and directory. - Make directory -- xen/include/asm-ia64/linux-null/asm-generic/ - Create zero-size header file -- xen/include/asm-ia64/linux-null/asm-generic/pci-dma-compat.h -- xen/include/asm-ia64/linux-null/asm/scatterlist.h -- xen/include/asm-ia64/linux-null/page-flags.h Note: rbtree.h is unnecessary. This patch is step2 which we showed by the following mail. http://lists.xensource.com/archives/html/xen-ia64-devel/2006-03/msg00305.html Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan and Akio remove.page.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] 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 vcpu_translate.patch Description: vcpu_translate.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275
On Fri, 2006-03-17 at 09:52 +0800, You, Yongkang wrote: Hi Alex, I am not very clear about the new Xen image and the old xenlinux kernel standard for. Does xenlinux kernel mean xenU kernel? Sorry for being unclear. Tristan's latest changes disable privop handling, requiring xen.gz and dom0 and domU kernels to be updated in parallel. Just be sure to do a make world and update all these at once and you shouldn't hit any problems. 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
RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275
KangKang, What that means is you have to run both Xen and XenLinux (both Xen0 XenU) built from the same Cset#. -Fred You, Yongkang wrote: Hi Alex, I am not very clear about the new Xen image and the old xenlinux kernel standard for. Does xenlinux kernel mean xenU kernel? Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006年3月17日 4:29 To: xen-ia64-devel Subject: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275 Please note, xen-ia64 cset 9275 will break functionality if a new xen images is used with an old xenlinux kernel. Please be sure to update your xenlinux image. 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 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] update linux kernels w/ xen-ia64 cset 9275
From: You,Yongkang Sent: 2006年3月17日 9:52 Hi Alex, I am not very clear about the new Xen image and the old xenlinux kernel standard for. Does xenlinux kernel mean xenU kernel? I think Alex is talking about some lazy way in daily development, due to fact that xen is updated more frequently than xenlinux for ia64. In that case, sometimes people may only recompile xen after pull latest changesets, and then run it with a xenlinux image compiled previously. Normally changes of structure and interface will need a complete make world. However normally people are not aware which changes require a complete make world. Some mismatch may be exposed easily like something previously runnable immediately fails now. However there're also some potential mismatches may generate weird behavior after long run, like some offset changes. So it's always safe though conservative to make world if time is allowed for developers. Maybe later we need a MODVERSION-like check between xen and xenlinux... :-) Thanks, Kevin Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006年3月17日 4:29 To: xen-ia64-devel Subject: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275 Please note, xen-ia64 cset 9275 will break functionality if a new xen images is used with an old xenlinux kernel. Please be sure to update your xenlinux image. 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 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] update linux kernels w/ xen-ia64 cset 9275
Alex/ Tristan Legacy privifiedinsns is being used; please turn on it by default. Pls refer to the attachment. Thanks, -Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006年3月17日 10:24 To: You, Yongkang Cc: xen-ia64-devel Subject: RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275 On Fri, 2006-03-17 at 09:52 +0800, You, Yongkang wrote: Hi Alex, I am not very clear about the new Xen image and the old xenlinux kernel standard for. Does xenlinux kernel mean xenU kernel? Sorry for being unclear. Tristan's latest changes disable privop handling, requiring xen.gz and dom0 and domU kernels to be updated in parallel. Just be sure to do a make world and update all these at once and you shouldn't hit any problems. 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 ---BeginMessage--- There are several of these that need to be changed, so let's change all of them the same way at the same time. It is still being used. At least, Dom0 uses pte.e to emulate fc. GLOBAL_ENTRY(xen_fc) 261 movl r8=running_on_xen;; 262 ld4 r8=[r8];; 263 cmp.eq p7,p0=r8,r0;; 264 (p7)fc r32;; 265 (p7)br.ret.sptk.many rp 266 ;; 267 ptc.e r96 // this is a privified fc r32 268 ;; 269 br.ret.sptk.many rp 270 END(xen_fc) Good catch. In fact, there are uses of this for several instructions still in xenlinux/ia64. Grep -sparse for privif to see all(?) of them. I think these never got translated to HYPERPRIVOPs because there was no performance need. But they should be fixed to avoid the possibility of a bug. ---End Message--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Step3 : Remove #define page_info page
From: Masaki Kanno Sent: 2006年3月17日 10:21 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH] Step3 : Remove #define page_info page Hi, This patch removed #define page_info page in asm-ia64/config.h. We tested compilation, booting dom0, and creation/destruction domU. This patch is step3 which we showed by the following mail. http://lists.xensource.com/archives/html/xen-ia64-devel/2006-03/msg00 305.html Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan and Akio Good work. And people are seeing and appreciating your effort to make xen/ia64 cleaner and more compact. Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275
Alex, I am using 9268. But I think all versions are using privified instructions, because this code is in sparse tree. Pls refer to inux-2.6-xen-sparse/include/asm-ia64/xen/privop.h extern unsigned long xen_fc(unsigned long addr); #define ia64_fc(addr) xen_fc((unsigned long)(addr)) extern unsigned long xen_thash(unsigned long addr); #define ia64_thash(addr)xen_thash((unsigned long)(addr)) Thanks, -Anthony -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年3月17日 10:46 To: Xu, Anthony Cc: You, Yongkang; xen-ia64-devel Subject: RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275 On Fri, 2006-03-17 at 10:34 +0800, Xu, Anthony wrote: Alex/ Tristan Legacy privifiedinsns is being used; please turn on it by default. Pls refer to the attachment. Anthony, The specific example cited is fixed in xen-ia64 9274. Are there other examples of where privified instructions are still in use? 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
RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275
On Fri, 2006-03-17 at 10:55 +0800, Xu, Anthony wrote: Alex, I am using 9268. But I think all versions are using privified instructions, because this code is in sparse tree. Pls refer to inux-2.6-xen-sparse/include/asm-ia64/xen/privop.h extern unsigned long xen_fc(unsigned long addr); #define ia64_fc(addr) xen_fc((unsigned long)(addr)) extern unsigned long xen_thash(unsigned long addr); #define ia64_thash(addr)xen_thash((unsigned long)(addr)) Anthony, Tristan has updated these to use the new hypercalls introduced in xen-ia64 cset 9273. If there still latent uses of privified instructions, I'll be happy to turn the default to enable them, but I believe they are all replaced by the new hypercalls if you do a full build from the latest changeset. 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
RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275
Alex, Okay. Thanks for your clarification. :) I usually do the make world for the new Cset. Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年3月17日 10:24 To: You, Yongkang Cc: xen-ia64-devel Subject: RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275 On Fri, 2006-03-17 at 09:52 +0800, You, Yongkang wrote: Hi Alex, I am not very clear about the new Xen image and the old xenlinux kernel standard for. Does xenlinux kernel mean xenU kernel? Sorry for being unclear. Tristan's latest changes disable privop handling, requiring xen.gz and dom0 and domU kernels to be updated in parallel. Just be sure to do a make world and update all these at once and you shouldn't hit any problems. 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
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 vcpu_translate.patch Description: vcpu_translate.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275
From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年3月17日 11:05 To: Xu, Anthony Cc: You, Yongkang; xen-ia64-devel Subject: RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275 Tristan has updated these to use the new hypercalls introduced in xen-ia64 cset 9273. If there still latent uses of privified instructions, I'll be happy to turn the default to enable them, but I believe they are all replaced by the new hypercalls if you do a full build from the latest changeset. Thanks, Alex Got it, they are not in the same patch. -- 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] 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
RE: [Xen-ia64-devel] [PATCH] XEN: fixed a vcpu_translate bug
Yes, it great! I also confirm it. Best Regards, Akio Takebe 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ト\xF3ヤツ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ト\xF3ヤツ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 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Weekly benchmark results [3/3rd week]
Hi, all I will inform this week's benchmark result. The tool used now is as follows. - unixbench4.1.0 - bonnie++-1.03 - ltp-full-20060306 - iozone3_191 - lmbench-3.0-a5 TEST ENVIRONMENT Machine : Tiger4 KERN : 2.6.16-rc5-xenU changeset: 9268:ab05373d6edd Dom0 OS : RHEL4 U2 (no SMP) DomU OS : RHEL4 U2 (no SMP) No. of DomU's: 1 SUMMARY: - The version of LTP did the up-grade from 20051205 to 20060306. issues: - Yongkang's dom0 timer issue occurred in my environment. TEST RESULT unixbench4.1.0: Pass bonnie++-1.03 : Pass ltp-full-20060306 : 52/817 FAIL iozone3_191 : Pass lmbench-3.0-a5: Pass Thanks and best regards, Fujita and Fujitsu members ltp-domU-20060316.log Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
