[Xen-ia64-devel] Re: [PATCH] kexec: framework and i386 (Take XIV)
Hi, Horms
That seems like a good idea to me. Though I think you are missing { }.
Can you test to see if this works?
Oops, You're right. But I think unknown_nmi_error() is not called,
because crash_kexec() is called before that.
Yes, I'll test it. :-)
--- a/xen/arch/x86/traps.c 2006-09-01 11:53:44.0 +0900
+++ b/xen/arch/x86/traps.c 2006-09-01 11:53:56.0 +0900
@@ -1611,8 +1611,10 @@
mem_parity_error(regs);
else if ( reason 0x40 )
io_check_error(regs);
-else if ( !nmi_watchdog )
+else if ( !nmi_watchdog ) {
+ crash_kexec(NULL);
unknown_nmi_error((unsigned char)(reason0xff));
+ }
}
}
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Re: [PATCH] kexec: framework and i386 (Take XIV)
Hi, Horms
That seems like a good idea to me. Though I think you are missing { }.
Can you test to see if this works?
Oops, You're right. But I think unknown_nmi_error() is not called,
because crash_kexec() is called before that.
Sorry.
In the only case of CONFIG_KEXEC=y, the above is right.
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Re: [PATCH] kexec: framework and i386 (Take XIV)
Hi, Horms
I tested the following patch with Horms kexec patch.
My tests is:
push NMI bottun after loading kdump kernel.
The results is:
OK, I could get vmcore
diff -r b688d4a68a3e xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c Tue Aug 22 14:59:16 2006 +0100
+++ b/xen/arch/x86/traps.c Tue Sep 05 06:37:49 2006 +0900
@@ -105,6 +105,8 @@ static int debug_stack_lines = 20;
static int debug_stack_lines = 20;
integer_param(debug_stack_lines, debug_stack_lines);
+extern void crash_kexec(struct cpu_user_regs *regs);
+
#ifdef CONFIG_X86_32
#define stack_words_per_line 8
#define ESP_BEFORE_EXCEPTION(regs) ((unsigned long *)regs-esp)
@@ -1611,8 +1613,10 @@ asmlinkage void do_nmi(struct cpu_user_r
mem_parity_error(regs);
else if ( reason 0x40 )
io_check_error(regs);
-else if ( !nmi_watchdog )
+else if ( !nmi_watchdog ){
+crash_kexec(NULL);
unknown_nmi_error((unsigned char)(reason0xff));
+}
}
}
Best Regards,
Akio Takebe
On Fri, Sep 01, 2006 at 05:45:59PM +0900, Akio Takebe wrote:
Hi, Horms
That seems like a good idea to me. Though I think you are missing { }.
Can you test to see if this works?
Oops, You're right. But I think unknown_nmi_error() is not called,
because crash_kexec() is called before that.
Sorry.
In the only case of CONFIG_KEXEC=y, the above is right.
Yes, I think that is the case. I will put your patch into the kexec
series, as I think that it is a worthy addition.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
___
Xen-devel mailing list
[EMAIL PROTECTED]
http://lists.xensource.com/xen-devel
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result
Hi, Yongkang I think this issue is configuration mistakes. Can you try the following configuration? I cannot try it because I meet another issue... 1. /etc/modprobe.conf for initrd of domU The following configuration would solve the issue of booting domU. [EMAIL PROTECTED] xen]# cat /etc/modprobe.conf #alias eth0 e1000 #alias scsi_hostadapter mptbase #alias scsi_hostadapter1 mptspi alias eth0 xennet this alias scsi_hostadapter xenblk and this 2. domU.conf The following configuration would solve the issue of probing ide disk. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,hda1,w' ] root = /dev/hda1 ro extra = 3 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe this Best Regards, Akio Takebe Hi, I have reported 2 bugs to redhat bugzilla: [Bug 207227] New: Xen0 reboot command can not reboot Tiger4 machine. [Bug 207241] New: XenU domain can not be created successfully. New xenU created failure serial log has been pasted to the bug. I also notice FC6-test3 Xen0 operation is a little slower, compared with RHEL4u3. I assign 2 vcpus to Xen0. When I destroy domains or do some heavy IO operations, Xen0 operations will be blocked for a while. I didn't track this to bugzilla. There are also a lot of unaligned accessing from some applications. They should be common FC6-test3 issues. Sometime Xen0 monitor will print Bug: soft lockup detected on CPU#0(or #1) Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of You, Yongkang Sent: 2006ト\xF3ヤツ20ネユ 10:07 To: Yang, Fred; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Hi Fred Yoshi, The former XenU creating failure issue seemed to be the config issue. Now I can create XenU. But XenU booting process met an old bug. It will cost a long time to check hard disk IRQ response from hda to hdh. After that, xenU met the problem of mounting root partition to start services, and then XenU booting failed (Kill init). I am not sure if it is because initrd issue. I will continue to check it. Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yang, Fred Sent: 2006ト\xF3ヤツ20ネユ 8:26 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Here it comes! -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 4:23 PM To: Yang, Fred; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Fred, Yongkang, Other issues: 1) Xen0 operation is a little slower than RHEL4u3. 2) XenU creating failure, please see attachment for the serial output. I can't find the attachment. Could you repost the serial log? Thanks, Yoshi Oguchi Yang, Fred [EMAIL PROTECTED] wrote」コ Following is the quick Xen test result with FC6 Test3. We will file BZ for the issues tonight; the early data is to get community to fix Xen issues ASAP Thanks, -Fred I have followed Redhat instructions (FC6-test3 can not be installed from CDs) to install FC6-Test3 and do some testing. Both Xen0 and VTI can all boot up, but XenU couldn't be created successfully. Detailed Items: 1. Using yum to upgrade FC6 Test2 to FC6 Test3[almost Pass] need manually reinstall kernel-xen rpm package. 2. Boot Native Linux of FC6 Test3 [Pass] 3. Boot Xen of FC6 Test3 [Pass] 4. xend and xm commands are working.[Pass] 5. XenU Domain creating failed. [__FAIL__] 6. Missing VTI guest firmware (/usr/lib/xen/boot/guest_firmware.bin) [__FAIL__ (expected)] 7. After manually copy VTI guest firmware, creating VTI domain [Pass] 8.VTI domain with network supported [Pass] 9.2 VTI domains coexisting testing [Pass] 10. Linux Kernel build in VTI domain [Pass] 11. LTP testing in VTI domain [Pass] 12. SMP VTI domain [Pass] 13. SMP Xen0 [Pass] 14. 1 VTI Windows 2k3 [Pass] a little slower. 15. 1 VTI Linux + 1 VTI Windows[__FAIL__ VTI Windows blue screen] 16. Reboot machine failed with Xen FC6-test3. [__FAIL__] Other issues: 1) Xen0 operation is a little slower than RHEL4u3. 2) XenU creating failure, please see attachment for the serial output. Best Regards, Yongkang (Kangkang) モタソオ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel
RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result
Hi, Yongkang I have a small mistake. Please try the following configuration. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,sda1,w' ] this root = /dev/sda1 ro this extra = 3 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe --- -this Best Regards, Akio Takebe Hi, Yongkang I think this issue is configuration mistakes. Can you try the following configuration? I cannot try it because I meet another issue... 1. /etc/modprobe.conf for initrd of domU The following configuration would solve the issue of booting domU. [EMAIL PROTECTED] xen]# cat /etc/modprobe.conf #alias eth0 e1000 #alias scsi_hostadapter mptbase #alias scsi_hostadapter1 mptspi alias eth0 xennet this alias scsi_hostadapter xenblk and this 2. domU.conf The following configuration would solve the issue of probing ide disk. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,hda1,w' ] root = /dev/hda1 ro extra = 3 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe this Best Regards, Akio Takebe Hi, I have reported 2 bugs to redhat bugzilla: [Bug 207227] New: Xen0 reboot command can not reboot Tiger4 machine. [Bug 207241] New: XenU domain can not be created successfully. New xenU created failure serial log has been pasted to the bug. I also notice FC6-test3 Xen0 operation is a little slower, compared with RHEL4u3. I assign 2 vcpus to Xen0. When I destroy domains or do some heavy IO operations, Xen0 operations will be blocked for a while. I didn't track this to bugzilla. There are also a lot of unaligned accessing from some applications. They should be common FC6-test3 issues. Sometime Xen0 monitor will print Bug: soft lockup detected on CPU#0(or #1) Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of You, Yongkang Sent: 2006トsヤツ20ネユ 10:07 To: Yang, Fred; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Hi Fred Yoshi, The former XenU creating failure issue seemed to be the config issue. Now I can create XenU. But XenU booting process met an old bug. It will cost a long time to check hard disk IRQ response from hda to hdh. After that, xenU met the problem of mounting root partition to start services, and then XenU booting failed (Kill init). I am not sure if it is because initrd issue. I will continue to check it. Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yang, Fred Sent: 2006トsヤツ20ネユ 8:26 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Here it comes! -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 4:23 PM To: Yang, Fred; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Fred, Yongkang, Other issues: 1) Xen0 operation is a little slower than RHEL4u3. 2) XenU creating failure, please see attachment for the serial output. I can't find the attachment. Could you repost the serial log? Thanks, Yoshi Oguchi Yang, Fred [EMAIL PROTECTED] wrote」コ Following is the quick Xen test result with FC6 Test3. We will file BZ for the issues tonight; the early data is to get community to fix Xen issues ASAP Thanks, -Fred I have followed Redhat instructions (FC6-test3 can not be installed from CDs) to install FC6-Test3 and do some testing. Both Xen0 and VTI can all boot up, but XenU couldn't be created successfully. Detailed Items: 1. Using yum to upgrade FC6 Test2 to FC6 Test3[almost Pass] need manually reinstall kernel-xen rpm package. 2. Boot Native Linux of FC6 Test3 [Pass] 3. Boot Xen of FC6 Test3 [Pass] 4. xend and xm commands are working.[Pass] 5. XenU Domain creating failed. [__FAIL__] 6. Missing VTI guest firmware (/usr/lib/xen/boot/guest_firmware.bin) [__FAIL__ (expected)] 7. After manually copy VTI guest firmware, creating VTI domain [Pass] 8.VTI domain with network supported [Pass] 9.2 VTI domains coexisting testing [Pass] 10. Linux Kernel build in VTI domain [Pass] 11. LTP testing in VTI domain [Pass] 12. SMP VTI domain [Pass] 13. SMP Xen0 [Pass] 14. 1 VTI Windows 2k3 [Pass] a little slower. 15. 1 VTI Linux + 1 VTI Windows[__FAIL__ VTI Windows blue screen] 16. Reboot machine failed with Xen FC6-test3. [__FAIL__] Other issues: 1) Xen0
[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Hi, Aron and all I can solve this problem by using dom0_mem=1G. FC6 test3 uses many daemons and services. Because booting xend is late, we fail insmod blk/netbk if dom0_mem=512M(default size). We may have to change dom0_mem of FC6 default to 1GB. But I think the best fix is (1) statically link the modules. (Because all kernel-xen need blkbk/netbk and xenblk/net. ide module is also static link. And because xen community member test the statically linked modules, I think the statically linked modules is stabler than the dynamic linked modlues.) Please give me some comments. Best Regards, Akio Takebe Presently the showstopper bug in Fedora Xen/ia64 is the failure of the blkbk/netbk modules to load. Akio Takebe and Kouya Shimura worked on a patch to fix this earlier (changeset bef360142b62), unfortunately it doesn't seem to have fixed the problem on the Fedora kernel. I filed the bug at RH: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202971 In that report, I suggest three options: (1) statically link the modules, (2) wait for xen-ia64-devel to finish xencomm, (3) debug the issue preventing the current drivers from loading. Regarding #1, I don't think RH will do it. Jeremy Katz has mentioned on the ML that Fedora is depending on the front/back-end drivers being compiled as modules. I'm looking forward to the completion of #2, but I think it would be wise to fix #3 if we can, especially since it might be easier. I have looked at it but I'm out of my depth. Would Kouya, Akio or somebody else mind trying to fix it? Note: I will have sporadic email contact starting tomorrow until Wednesday 9/27, so I may not respond until then. Thanks, Aron ---application/pgp-signature--- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFEzj8JrHF4yAQTrARAuLWAJ4v2e4HFnmyq01n48SC0PKIK3gjyACdGRI+ Wv/7SXoRNtXgssrk42mlfB8= =hoQO -END PGP SIGNATURE- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result
Hi, Yongkang and all I can boot up domU by using my special initrd without vif. I think mkinitrd of fc6 make initrd by using dom0 infomation. (for example dom0's /etc/fstab, dom0's pci infomaition. ) So when xm boot domU, domU kernel don't use bootparmeter of domU. The below is a recipe of making my special inird 1. copy initrd # mkdir tmp # cp /boot/efi/efi/redhat/initrd-2.6.18-1.2679.fc6xenU.img tmp/ 2. expand inird # cd tmp # gzip -cd ../initrd-2.6.18-1.2679.fc6xenU.img |cpio -id 3. modify init in initrd # vi init insmod /lib/ohci-hcd.ko echo Loading ehci-hcd.ko module insmod /lib/ehci-hcd.ko mount -t usbfs /proc/bus/usb /proc/bus/usb echo Loading jbd.ko module insmod /lib/jbd.ko echo Loading ext3.ko module insmod /lib/ext3.ko #echo Loading scsi_mod.ko modulecomment out #insmod /lib/scsi_mod.ko comment out #echo Loading sd_mod.ko module comment out #insmod /lib/sd_mod.kocomment out #echo Loading scsi_transport_spi.ko module comment out #insmod /lib/scsi_transport_spi.kocomment out #echo Loading mptbase.ko module comment out #insmod /lib/mptbase.ko comment out #echo Loading mptscsih.ko modulecomment out #insmod /lib/mptscsih.ko comment out #echo Loading mptspi.ko module comment out #insmod /lib/mptspi.kocomment out echo Loading xenblk.ko module insmod /lib/xenblk.ko mkblkdevs #resume LABEL=SWAP-sda3 comment out echo Creating root device. mkrootdev -t ext3 -o defaults,ro sda1 change device to sda1 echo Mounting root filesystem. mount /sysroot echo Setting up other filesystems. setuproot echo Switching to new root and running init. switchroot 4. make new initrd # find . -print | cpio --quiet -c -o | gzip -9 ../initrd-new.img 5. my domU configuration kernel = /boot/efi/efi/redhat/vmlinuz-2.6.18-1.2679.fc6xen ramdisk = /xen/initrd-new.img memory = 1024 name = fc6.DomU #vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,sda1,w' ] root = /dev/sda1 ro extra = 4 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe selinux=0 rhgb 6. etc 6.1. copy modlues into domU image file # mount -o loop domU.img /mnt # cp -a /lib/modules/2.6.18-1.2679.fc6xen/ /mnt/lib/modules/ 6.2. disable selinux # vi /etc/sysconfig/selinux SELINUX=disabled change enforcing to disabled 6.3. modify /etc/fstab in domU.img /dev/sda1 / ext3defaults1 1 devpts/dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults0 0 proc /proc procdefaults0 0 sysfs /sys sysfs defaults0 0 But I cannot use network on domU. I'll check the src.rpm of kernel-xen. Best Regards, Akio Takebe Hi Akio, Sorry for response late. I just tried with the config you provide (I changed xenU modprobe.conf and fstab). But unfortunately it still couldn't work. XenU booting still report can not find filesystem /dev/root/ and kernel panic. Well, after add ide0=noprobe etc. xenU won't complain to check hda, hdb etc. again. Thanks for this information. Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006ト\xF3ヤツ21ネユ 10:18 To: Akio Takebe; You, Yongkang; Yang, Fred; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Hi, Yongkang I have a small mistake. Please try the following configuration. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,sda1,w' ] this root = /dev/sda1 ro this extra = 3 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe --- -this Best Regards, Akio Takebe Hi, Yongkang I think this issue is configuration mistakes. Can you try the following configuration? I cannot try it because I meet another issue... 1. /etc/modprobe.conf for initrd of domU The following configuration would solve the issue of booting domU. [EMAIL PROTECTED] xen]# cat /etc/modprobe.conf #alias eth0 e1000 #alias scsi_hostadapter mptbase #alias scsi_hostadapter1 mptspi alias eth0 xennet this alias scsi_hostadapter xenblk and this 2. domU.conf The following configuration would solve the issue of probing ide disk. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen
[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Hi, Aron and all We may have to change dom0_mem of FC6 default to 1GB. But I think the best fix is (1) statically link the modules. (Because all kernel-xen need blkbk/netbk and xenblk/net. ide module is also static link. And because xen community member test the statically linked modules, I think the statically linked modules is stabler than the dynamic linked modlues.) I don't mind asking RH to statically link the modules if there is good reason. However I don't understand why it is needed. 512M is a lot of memory! How can it be filled to the extent that the blkbk/netbk modules won't load? What are their requirements? Please see the following error message. FATAL: Error inserting blkbk (/lib/modules/2.6.17-1.2566.fc6xen/kernel/drivers/xen/ blkback/blkbk.ko): Cannot allocate memory modprobe: page allocation failure. order:8, mode:0xd0 blkbk.ko request order8 pages in blkif_init(). order8 pages is very big. page_alloc() probably fail when it is requested order8 pages, because page_alloc() must return contiguos pages. Especially after boot and terminate some processes, page_alloc() is hard to allocate order8 pages. So when dom0_mem=1G, page_allo() is easier to allocate them than dom0_mem=512M. And when statically linked modules, page_alloc() is the easest to allocate them. I think implementation of blk/netbk.ko is not good. But I think statically linked modules is the best solution in your solutions. And I think this issue is happened in the case of not only ia64, but also x86. (In the case of x86, default size of dom0_mem is physcal memory size. So this issue is hard to be happened.) Please commets. FYI https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202971 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] [Fedora-ia64-list] FC6 Test3 Xen test result
Hi, Yongkang Hi Akio, Sorry for response late. It is very detailed instructions. :) I found my initrd doesn't preload xenblk.ko. Then it failed to create root device. Now I can create xenU too with your guide. Thank you so much. But did you notice xenU booting is a little slow? Yes, starting sendmail is very slow. I also suspected dom0/domU hanged up. :-) 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] FC6 Test3 Xentest result
Hi, Yongkang Thank you for your report. I have the same bug. Aron reported the likely bug of xenguest-install.py. I try to debug this issue. Best Regards, Akio Takebe Hi Aron and Akio, I reported a new bug about Xen0 crashing, when I try to insert xennet.ko in XenU. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208062 Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aron Griffis Sent: 2006ト\xF3ヤツ21ネユ 22:45 To: You, Yongkang Cc: xen-ia64-devel@lists.xensource.com; [EMAIL PROTECTED] Subject: [Fedora-xen] Re: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xentest result You, Yongkang wrote: [Wed Sep 20 2006, 01:46:22AM EDT] [Bug 207227] New: Xen0 reboot command can not reboot Tiger4 machine. I think this is a duplicate of bug 203032. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203032 [Bug 207241] New: XenU domain can not be created successfully. New xenU created failure serial log has been pasted to the bug. I think the front-end and back-end drivers aren't communicating. I see the same problem with both network and block drivers when attempting xenguest-install. Aron -- Fedora-xen mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/fedora-xen ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm
: ia64 nr_cpus: 16 nr_nodes : 1 sockets_per_node : 4 cores_per_socket : 2 threads_per_core : 2 cpu_mhz: 1595 hw_caps: ::::: ::: total_memory : 8166 free_memory: 7075 xen_major : 3 xen_minor : 0 xen_extra : -unstable xen_caps : xen-3.0-ia64 hvm-3.0-ia64 xen_pagesize : 16384 platform_params: virt_start=0xe800 xen_changeset : Tue Sep 26 19:11:33 2006 -0600 11635: f34e37d0742d cc_compiler: gcc version 3.4.4 20050721 (Red Hat 3.4.4-2) cc_compile_by : root cc_compile_domain : cc_compile_date: Thu Sep 28 10:01:11 JST 2006 xend_config_format : 2 Best Regards, Akio Takebe Hi, here are 3 patches for xencomm. The first one (a2) is the xencomm in itself. Compatibility is broken. The second one (b2) renumbered dom0vp. Because compatibility is broken dom0vp can be renumbered safely. [Are there good reasons why the numbering was sparse ?] The last one (c2) is a small optimization for physdevop eoi. tested by booting domU with netbk,netloop and blkbk as modules in dom0. Tristan. ---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: blkbk/netbk modules fail to load on fedora xen/ia64
Hi, Aron and all netbk/xennet modules fail to load by using xen-ia64-unstable again. This issue is caused by the following patches. http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=c757ebffd500 We can probably resolve this issue. 1. Tristan's xencomm patches is applied. (I test by using xen-ia64-unstable, but these patches have some issue.) 2. revert the below patch. (I have not test yet.) 3. built in these modules. (I have not test yet.) I think the best way is 1. But Tristan's patches still have some issues. What do you think about this? Best Regards, Akio Takebe Akio Takebe wrote: [Thu Sep 21 2006, 09:53:16PM EDT] I can solve this problem by using dom0_mem=1G. This allows blkbk/netbk to load, but I guess a domU won't install yet. xenguest-install fails with a panic in dom0. I used this command: xenguest-install -n domu -r 1024 -f /root/domu.img \ -l http://hummer.zko.hp.com/fedora/linux/core/development/ia64/os/ \ -s 4 --nographics -p -x 'ide0=noprobe ide1=noprobe ide2=noprobe ide3= noprobe' Here is the output on the dom0 console: (XEN) ### domain f7bb4080: rid=8-c mp_rid=2000 (XEN) arch_domain_create: domain=f7bb4080 (XEN) DomainU EFI build up: ACPI 2.0=0x1000 (XEN) dom mem: type=13, attr=0x8008, range=[0x- 0x1000) (4KB) (XEN) dom mem: type=10, attr=0x8008, range=[0x1000- 0x2000) (4KB) (XEN) dom mem: type= 6, attr=0x8008, range=[0x2000- 0x3000) (4KB) (XEN) dom mem: type= 7, attr=0x0008, range=[0x3000- 0x3fff4000) (1023MB) (XEN) dom mem: type=12, attr=0x0001, range=[0x0c00- 0x1000) (64MB) audit(1158891786.948:4): dev=vif1.0 prom=256 old_prom=0 auid=4294967295 kernel unaligned access to 0xa002009e405f, ip=0xa00100295e91 kernel unaligned access to 0xa002009e4067, ip=0xa00100295e91 kernel unaligned access to 0xa002009e406f, ip=0xa00100295e91 kernel unaligned access to 0xa002009e4077, ip=0xa00100295e91 kernel unaligned access to 0xa002009e407f, ip=0xa00100295e91 (XEN) vcpu_get_lrr0: Unmasked interrupts unsupported (XEN) vcpu_get_lrr1: Unmasked interrupts unsupported (XEN) Linux version 2.6.18-1.2679.fc6xen ([EMAIL PROTECTED] com) (gcc version 4.1.1 20060917 (Red Hat 4.1.1-23)) #1 SMP Wed Sep 20 01: 18:10 EDT 2006 EFI v1.00 by Xen/ia64: SALsystab=0x2178 ACPI 2.0=0x1000 rsvd_region[0]: [0xe0002228, 0xe00022f0) rsvd_region[1]: [0xe0003000, 0xe0003030) rsvd_region[2]: [0xe400, 0xe4c2899b) rsvd_region[3]: [0xe4c2c000, 0xe597ac00) rsvd_region[4]: [0xe0003fff4000, 0xe0003fff8000) rsvd_region[5]: [0x, 0x) Initial ramdisk at: 0xe4c2c000 (13954048 bytes) SAL 0.1: Xen/ia64 Xen/ia64 version 0.0 SAL: AP wakeup using external interrupt vector 0xf3 xen_pal_emulator: UNIMPLEMENTED PAL CALL 42 (XEN) No logical to physical processor mapping available ACPI: Local APIC address c000fee0 ACPI: Error parsing MADT - no IOSAPIC entries 1 CPUs available, 1 CPUs total Running on Xen! start_info_pfn=0xfffd nr_pages=65536 flags=0x0 *** CALLED SAL_MC_SET_PARAMS. IGNORED... (XEN) *** CALLED SAL_MC_SET_PARAMS. IGNORED... (XEN) *** CALLED SAL_SET_VECTORS 0. IGNORED... (XEN) *** CALLED SAL_SET_VECTORS 1. IGNORED... (XEN) MCA related initialization done SMP: Allowing 1 CPUs, 0 hotplug CPUs Built 1 zonelists. Total pages: 61440 Kernel command line: method=http://hummer.zko.hp.com/fedora/linux/core/ development/ia64/os/ ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe ide_setup: ide0=noprobe ide_setup: ide1=noprobe ide_setup: ide2=noprobe ide_setup: ide3=noprobe PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour dummy device 80x25 (file=grant_table.c, line=704) gnttab_transfer: error writing resp 0/1 kernel BUG at drivers/xen/netback/netback.c:631! swapper[0]: bugcheck! 0 [1] Modules linked in: loop xt_physdev bridge netloop netbk blkbk autofs4 hidp rfcomm l2cap bluetooth sunrpc ip_conntrack_netbios_ns ipt_REJECT iptable_filter ip_tables xt_state ip_conntrack nfnetlink xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 vfat fat dm_multipath button parport_pc lp parport ide_cd sg e1000 cdrom dm_snapshot dm_zero dm_mirror dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 0, CPU 0, comm: swapper psr : 001008026010 ifs : 8694 ip : [a00200c80590] Not tainted ip is at net_rx_action+0x990/0x17a0 [netbk] unat: pfs : 8694 rsc : 0008 rnat: bsps: pr : 00019665 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a00200c80590 b6 : a001000b80c0 b7
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Hi, Tristan I tried to test your patches. And I don't meet the network issue. good work!!! I'll try to test my network load test. I had some unaligned access message. For your infomation, I show the log. PING 10.124.36.60 (10.124.36.60) 56(84) bytes of data. kernel unaligned access to 0xe00019247a1e, ip=0xa0010093d681 kernel unaligned access to 0xe00019247a1e, ip=0xa0010093d751 kernel unaligned access to 0xe00019247a1e, ip=0xa0010093d800 kernel unaligned access to 0xe00019247a2e, ip=0xa0010093da10 kernel unaligned access to 0xe00019247a1e, ip=0xa0010093da90 64 bytes from 10.124.36.60: icmp_seq=0 ttl=126 time=42.7 ms 64 bytes from 10.124.36.60: icmp_seq=1 ttl=126 time=2.31 ms 64 bytes from 10.124.36.60: icmp_seq=2 ttl=126 time=2.28 ms 64 bytes from 10.124.36.60: icmp_seq=3 ttl=126 time=2.29 ms 64 bytes from 10.124.36.60: icmp_seq=4 ttl=126 time=2.30 ms 64 bytes from 10.124.36.60: icmp_seq=5 ttl=126 time=2.29 ms kernel unaligned access to 0xe0001918d21e, ip=0xa0010093d681 kernel unaligned access to 0xe0001918d21e, ip=0xa0010093d751 kernel unaligned access to 0xe0001918d21e, ip=0xa0010093d800 kernel unaligned access to 0xe0001918d22e, ip=0xa0010093da10 kernel unaligned access to 0xe0001918ca1e, ip=0xa0010093d681 64 bytes from 10.124.36.60: icmp_seq=6 ttl=126 time=32.6 ms 64 bytes from 10.124.36.60: icmp_seq=7 ttl=126 time=2.24 ms 64 bytes from 10.124.36.60: icmp_seq=8 ttl=126 time=2.38 ms 64 bytes from 10.124.36.60: icmp_seq=9 ttl=126 time=2.26 ms 64 bytes from 10.124.36.60: icmp_seq=10 ttl=126 time=2.25 ms 64 bytes from 10.124.36.60: icmp_seq=11 ttl=126 time=2.24 ms Best Regards, Akio Takebe Hi, thanks to Alex and Akio for more torough testing. I have fixed the xentop issue. I think I have also fixed the network issue: during the tests I never hit it. My tests were booting dom0+2*dom_U (using netbk, blkbk and netloop as modules), and doing ping+wget from domU_1. Tristan. ---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: xencomm [2]
Hi, Aron
I think this issue do not relate xencomm and copy_from/to_user.
This issue is caused by page_alloc of net/blkbk module.
order:8 is too big.
After forked and terminated some process,
alloc_page() of oder:8 almost fail.
So builtin module don't have this issue because none of process is created
before initialization of these module.
The solutions of this issue are:
1. fix memory allocation of blkbk, netbk
2. builtin blkbk, netbk
3. allocate big memory to dom0
See the following code.
static int __init blkif_init(void)
{
struct page *page;
int i;
if (!is_running_on_xen())
return -ENODEV;
mmap_pages= blkif_reqs * BLKIF_MAX_SEGMENTS_PER_REQUEST;
too big
page = balloon_alloc_empty_page_range(mmap_pages); alloc_page()
if (page == NULL)
return -ENOMEM;
mmap_vstart = (unsigned long)pfn_to_kaddr(page_to_pfn(page));
Best Regards,
Akio Takebe
Hi Tristan,
Tristan Gingold wrote: [Thu Sep 28 2006, 07:33:28AM EDT]
My tests were booting dom0+2*dom_U (using netbk, blkbk and netloop as
modules), and doing ping+wget from domU_1.
I tested these patches on the Fedora rawhide kernel, but I still see
the memory allocation failure when trying to load the netbk or blkbk
modules in dom0.
I thought that these patches would solve this problem, but the netbk
module isn't touched. Could you comment?
Thanks,
Aron
modprobe: page allocation failure. order:8, mode:0xd0
Call Trace:
[a0010001c8e0] show_stack+0x40/0xa0
sp=e0001fdffc20 bsp=e0001fdf9240
[a0010001c970] dump_stack+0x30/0x60
sp=e0001fdffdf0 bsp=e0001fdf9228
[a0010010b220] __alloc_pages+0x500/0x540
sp=e0001fdffdf0 bsp=e0001fdf91b0
[a0010010b310] __get_free_pages+0xb0/0x140
sp=e0001fdffe00 bsp=e0001fdf9188
[a001003c7400] balloon_alloc_empty_page_range+0x80/0x400
sp=e0001fdffe00 bsp=e0001fdf9140
[a002000cc190] netback_init+0x190/0x5c0 [netbk]
sp=e0001fdffe30 bsp=e0001fdf9108
[a001000d1dc0] sys_init_module+0x180/0x400
sp=e0001fdffe30 bsp=e0001fdf9098
[a00100014100] ia64_ret_from_syscall+0x0/0x40
sp=e0001fdffe30 bsp=e0001fdf9098
[a0010620] __start_ivt_text+0x00010620/0x400
sp=e0001fe0 bsp=e0001fdf9098
Mem-info:
DMA per-cpu:
cpu 0 hot: high 42, batch 7 used:14
cpu 0 cold: high 14, batch 3 used:13
DMA32 per-cpu: empty
Normal per-cpu: empty
HighMem per-cpu: empty
Free pages: 22416kB (0kB HighMem)
Active:5579 inactive:9841 dirty:269 writeback:0 unstable:0 free:1401 slab:
1139 mapped:1143 pagetables:151
DMA free:22416kB min:2896kB low:3616kB high:4336kB active:89264kB inactive:
157456kB present:524288kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:
0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
HighMem free:0kB min:512kB low:512kB high:512kB active:0kB inactive:0kB
present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 169*16kB 96*32kB 50*64kB 21*128kB 8*256kB 5*512kB 4*1024kB 1*2048kB 0*
4096kB 0*8192kB 0*16384kB = 22416kB
DMA32: empty
Normal: empty
HighMem: empty
Swap cache: add 0, delete 0, find 0/0, race 0+0
Free swap = 2031584kB
Total swap = 2031584kB
Free swap: 2031584kB
32768 pages of RAM
13277 reserved pages
5037 pages shared
0 pages swap cached
13 pages in page table cache
___
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: xencomm [2]
Hi, Aron Tristan Gingold wrote: [Fri Sep 29 2006, 10:44:48AM EDT] Does this bug occur on x86 ? No. Aron Hmmm... But this issue was happened on x86-PAE. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201796 Actually with dom0_mem=512M on FC6-ia64, we can success installing blkbk on rare occasions. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Hi, Aron However on ia64 this isn't sufficient. We need either for the modules to load *earlier* (such as in the initramfs) or we need to use dom0_mem=1G (for example) I have some questions, though: 1. On x86, all of the memory is assigned to dom0, then it balloons to give memory to unpriv'd domains. Why does ia64 give only 512M to dom0 instead of doing the same as x86? I don't know, but I think this is for historical reasons. Old Xen/IA64 (about 1 year ago) used only about 2GB. So I think dom0_mem was defined to 512MB. I made the patch, but the patch have a problem. I'm debug it now. 2. Juan says that he can boot x86 xen with only 128M of memory, and there's still enough physically contiguous to load blkbk and netbk when xend loads. So why does ia64 need 8x the memory to do avoid fragmentation? It seems like we must be doing something wrong for memory to fragment so quickly...! I also don't know about it. This is strange, but insmod blkbk will fail in the following case on x86. 1. chkconfig xend off 2. and do many operations after boot 3. then service xend start --- insmod blkbk fail (probably) On PAE the problem was fixed by loading blkbk/netbk in /etc/init.d/xend. This moves the module load early enough in the system boot to fix it on that arch. So the above solution is not good. If we choice the early module load solution, we should add it into rc.sysinit. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Hi, Aron I checked the fragmentation on xen/ia64 with on xen/x86. The following data is /proc/budddyinfo after starting each daemons. 1. buddyinfo of ia64 at the boottime. (dom0_mem=512MB) Mon Oct 2 20:42:24 JST 2006 --iptables--- Node 0, zone DMA 1 2 1 1 1 1 0 0 0 1 9 --iptables--- --portmap--- Node 0, zone DMA 0 1 1 1 1 0 1 0 1 0 1 --portmap--- --ssh--- Node 0, zone DMA 1 3 9 3 1 1 1 1 0 0 0 --ssh--- --sendmail--- Node 0, zone DMA 19 7 5 1 5 1 0 1 0 0 0 --sendmail--- --haldaemon--- Node 0, zone DMA 20 10 5 1 4 0 1 1 0 0 0 --haldaemon--- 2. buddyinfo of x86 at the boottime. (dom0_mem=128MB) Mon Oct 2 21:22:29 JST 2006 --iptables--- Node 0, zone DMA 47 11 4 1 0 1 8 4 1 0 11 --iptables--- --portmap--- Node 0, zone DMA 3 2 0 1 0 0 1 0 1 1 9 --portmap--- --ssh--- Node 0, zone DMA 23 3 1 1 1 1 1 3 2 0 3 --ssh--- --sendmail--- Node 0, zone DMA 26 5 4 0 0 0 4 3 3 1 1 --sendmail--- --haldaemon--- Node 0, zone DMA 44 14 23 14 2 1 1 0 1 0 0 --haldaemon--- --before stating xend--- Node 0, zone DMA 22 25 24 14 2 1 1 0 1 0 0 --before stating xend--- I think fragmentations of ia64 is a little quickly. But allocate of oder:8 is hard on also x86 at the starting of xend. My Xen/IA64 environment have 16 cpus(4 sockets, 8cores, 16threads), and Xen/x86 environment have 2core cpus(1 sockets, 2cores). The difference of the fragmentations may be caused by the number of cpus. What do you think about it? Best Regards, Akio Takebe Akio Takebe wrote: [Fri Sep 29 2006, 11:41:57AM EDT] Hmmm... But this issue was happened on x86-PAE. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201796 Actually with dom0_mem=512M on FC6-ia64, we can success installing blkbk on rare occasions. On PAE the problem was fixed by loading blkbk/netbk in /etc/init.d/xend. This moves the module load early enough in the system boot to fix it on that arch. However on ia64 this isn't sufficient. We need either for the modules to load *earlier* (such as in the initramfs) or we need to use dom0_mem=1G (for example) I have some questions, though: 1. On x86, all of the memory is assigned to dom0, then it balloons to give memory to unpriv'd domains. Why does ia64 give only 512M to dom0 instead of doing the same as x86? 2. Juan says that he can boot x86 xen with only 128M of memory, and there's still enough physically contiguous to load blkbk and netbk when xend loads. So why does ia64 need 8x the memory to do avoid fragmentation? It seems like we must be doing something wrong for memory to fragment so quickly...! Thanks, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0
Hi, all This patch change default value of dom0_mem. Current xen/ia64, default value of dom0_mem is 512MB. This patch change it from 512MB to almost total memory(like xen/x86). Signed-off-by: Akio Takebe [EMAIL PROTECTED] I test the patch. But I have a problem. I cannot boot current xen/ia64 with dom0_mem=4G. The below is boot log. \ \/ /___ _ __ |___ / / _ \_ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \|_ \| | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | ___) | |_| |__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |(_)___/\__,_|_| |_|___/\__\__,_|_.__/|_|\___| http://www.cl.cam.ac.uk/netos/xen University of Cambridge Computer Laboratory Xen version 3.0-unstable (root@) (gcc version 3.4.4 20050721 (Red Hat 3. 4.4-2)) Mon Oct 2 19:27:12 JST 2006 Latest ChangeSet: Sun Oct 01 19:10:18 2006 -0600 11701:2bfd19fc1b79 (XEN) Console output is synchronous. (XEN) Xen command line: BOOT_IMAGE=scsi0:\EFI\redhat\../xen/xen.gz- takebe dom0_mem=4G com2=115200,8n1 console=com2,vga sync_console (XEN) xen image pstart: 0x400, xenheap pend: 0x800 (XEN) Xen patching physical address access by offset: 0x0 (XEN) find_memory: efi_memmap_walk returns max_page=bffee (XEN) Before xen_heap_start: f4129bd8 (XEN) After xen_heap_start: f4148000 (XEN) Init boot pages: 0x1d8 - 0x400. (XEN) Init boot pages: 0x800 - 0x7f708000. (XEN) Init boot pages: 0x7fe58000 - 0x7feb8000. (XEN) Init boot pages: 0x1 - 0x1c000. (XEN) Init boot pages: 0x28000 - 0x2fd99b000. (XEN) Init boot pages: 0x2fe806eb0 - 0x2fedec010. (XEN) Init boot pages: 0x2fedec070 - 0x2fedeff59. (XEN) Init boot pages: 0x2fedeffc7 - 0x2fedf3000. (XEN) Init boot pages: 0x2fef319d4 - 0x2fef4e010. (XEN) Init boot pages: 0x2fef4ea00 - 0x2ffe14000. (XEN) Init boot pages: 0x2ffe8 - 0x2fffb8000. (XEN) System RAM: 8166MB (8362688kB) (XEN) size of virtual frame_table: 20480kB (XEN) virtual machine to physical table: f3a00090 size: 4144kB (XEN) max_page: 0xbffee (XEN) Xen heap: 62MB (64224kB) (XEN) ACPI: RSDP (v002 INTEL ) @ 0x7ff0c000 (XEN) ACPI: XSDT (v001 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x7ff0c090 (XEN) ACPI: FADT (v003 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x7ff0c138 (XEN) ACPI: MADT (v001 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x7ff0c230 (XEN) ACPI: DSDT (v001 Intel SR870BN4 0x INTL 0x20030918) @ 0x (XEN) SAL 3.20: Intel Corp SR870BN4 version 3.0 (XEN) SAL Platform features: BusLock (XEN) SAL: AP wakeup using external interrupt vector 0xf0 (XEN) cpu package is Multi-Core capable: number of cores=2 (XEN) cpu package is Multi-Threading capable: number of siblings=2 (XEN) avail:0x31700740, status:0x740,control: 0x3170, vm?0x100 (XEN) WARNING: no opcode provided from hardware(0)!!! (XEN) vm buffer size: 1048576, order: 6 (XEN) cpu_init: current=f40d8000 (XEN) vm_buffer: 0xf7e0 (XEN) vhpt_init: vhpt paddr=0x1fffe, end=0x1fffe (XEN) iosapic_system_init: Disabling PC-AT compatible 8259 interrupts (XEN) ACPI: Local APIC address e800fee0 (XEN) ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0xc4] lsapic_eid[0x18] enabled) (XEN) CPU 0 (0xc418) enabled (BSP) (XEN) ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0xc6] lsapic_eid[0x18] enabled) (XEN) CPU 1 (0xc618) enabled (XEN) ACPI: LSAPIC (acpi_id[0x02] lsapic_id[0xc1] lsapic_eid[0x18] enabled) (XEN) CPU 2 (0xc118) enabled (XEN) ACPI: LSAPIC (acpi_id[0x03] lsapic_id[0xc3] lsapic_eid[0x18] enabled) (XEN) CPU 3 (0xc318) enabled (XEN) ACPI: LSAPIC (acpi_id[0x04] lsapic_id[0xc5] lsapic_eid[0x18] enabled) (XEN) CPU 4 (0xc518) enabled (XEN) ACPI: LSAPIC (acpi_id[0x05] lsapic_id[0xc7] lsapic_eid[0x18] enabled) (XEN) CPU 5 (0xc718) enabled (XEN) ACPI: LSAPIC (acpi_id[0x06] lsapic_id[0xc0] lsapic_eid[0x98] enabled) (XEN) CPU 6 (0xc098) enabled (XEN) ACPI: LSAPIC (acpi_id[0x07] lsapic_id[0xc2] lsapic_eid[0x98] enabled) (XEN) CPU 7 (0xc298) enabled (XEN) ACPI: LSAPIC (acpi_id[0x08] lsapic_id[0xc4] lsapic_eid[0x98] enabled) (XEN) CPU 8 (0xc498) enabled (XEN) ACPI: LSAPIC (acpi_id[0x09] lsapic_id[0xc6] lsapic_eid[0x98] enabled) (XEN) CPU 9 (0xc698) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0a] lsapic_id[0xc1] lsapic_eid[0x98] enabled) (XEN) CPU 10 (0xc198) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0b] lsapic_id[0xc3] lsapic_eid[0x98] enabled) (XEN) CPU 11 (0xc398) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0c] lsapic_id[0xc5] lsapic_eid[0x98] enabled) (XEN) CPU 12 (0xc598) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0d] lsapic_id[0xc7] lsapic_eid[0x98] enabled) (XEN) CPU 13 (0xc798) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0e] lsapic_id[0xc0] lsapic_eid[0x18] enabled) (XEN) CPU 14 (0xc018) enabled (XEN) ACPI: LSAPIC (acpi_id[0x0f] lsapic_id
Re: [Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0
Hi,
Also in the case of current Xen-ia64-unstable(cset:11721),
this panic is occured by specified dom0_mem=4G.
(without my patch)
I think the following error message is hint of this bug.
(XEN) Warning: UC to WB for mpaddr=f9ff
I checked the arch/ia64/xen/mm.c
Why changing pteval2 from UC to WB is OK?
If pteval2 is WB and pteval is UC, should pteval2 be changed to UC?
Please comments.
Isaku, what do you think about it?
u64 translate_domain_pte(u64 pteval, u64 address, u64 itir__, u64* logps,
struct p2m_entry* entry)
{
struct domain *d = current-domain;
ia64_itir_t itir = {.itir = itir__};
u64 mask, mpaddr, pteval2;
u64 arflags;
u64 arflags2;
u64 maflags2;
pteval = ((1UL 53) - 1);// ignore [63:53] bits
// FIXME address had better be pre-validated on insert
mask = ~itir_mask(itir.itir);
mpaddr = ((pteval _PAGE_PPN_MASK) ~mask) | (address mask);
if (itir.ps PAGE_SHIFT)
itir.ps = PAGE_SHIFT;
*logps = itir.ps;
pteval2 = lookup_domain_mpa(d, mpaddr, entry);
/* Check access rights. */
arflags = pteval _PAGE_AR_MASK;
arflags2 = pteval2 _PAGE_AR_MASK;
if (arflags != _PAGE_AR_R arflags2 == _PAGE_AR_R) {
[snip..]
pteval = (pteval ~_PAGE_AR_MASK) | _PAGE_AR_R;
}
/* Check memory attribute. The switch is on the *requested* memory
attribute. */
maflags2 = pteval2 _PAGE_MA_MASK;
switch (pteval _PAGE_MA_MASK) {
case _PAGE_MA_NAT:
/* NaT pages are always accepted! */
break;
case _PAGE_MA_UC:
case _PAGE_MA_UCE:
case _PAGE_MA_WC:
if (maflags2 == _PAGE_MA_WB) {
/* Don't let domains WB-map uncached addresses.
This can happen when domU tries to touch i/o
port space. Also prevents possible address
aliasing issues. */
printf(Warning: UC to WB for mpaddr=%lx\n, mpaddr);
pteval = (pteval ~_PAGE_MA_MASK) | _PAGE_MA_WB;
this
}
break;
case _PAGE_MA_WB:
if (maflags2 != _PAGE_MA_WB) {
/* Forbid non-coherent access to coherent memory. */
panic_domain(NULL, try to use WB mem attr on
UC page, mpaddr=%lx\n, mpaddr);
}
break;
Best Regards,
Akio Takebe
Hi, all
This patch change default value of dom0_mem.
Current xen/ia64, default value of dom0_mem is 512MB.
This patch change it from 512MB to almost total memory(like xen/x86).
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
I test the patch.
But I have a problem.
I cannot boot current xen/ia64 with dom0_mem=4G.
The below is boot log.
\ \/ /___ _ __ |___ / / _ \_ _ _ __ ___| |_ __ _| |__ | | ___
\ // _ \ '_ \|_ \| | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
/ \ __/ | | | ___) | |_| |__| |_| | | | \__ \ || (_| | |_) | | __/
/_/\_\___|_| |_| |(_)___/\__,_|_| |_|___/\__\__,_|_.__/|_|\___|
http://www.cl.cam.ac.uk/netos/xen
University of Cambridge Computer Laboratory
Xen version 3.0-unstable (root@) (gcc version 3.4.4 20050721 (Red Hat 3.
4.4-2)) Mon Oct 2 19:27:12 JST 2006
Latest ChangeSet: Sun Oct 01 19:10:18 2006 -0600 11701:2bfd19fc1b79
(XEN) Console output is synchronous.
(XEN) Xen command line: BOOT_IMAGE=scsi0:\EFI\redhat\../xen/xen.gz-
takebe dom0_mem=4G com2=115200,8n1 console=com2,vga sync_console
(XEN) xen image pstart: 0x400, xenheap pend: 0x800
(XEN) Xen patching physical address access by offset: 0x0
(XEN) find_memory: efi_memmap_walk returns max_page=bffee
(XEN) Before xen_heap_start: f4129bd8
(XEN) After xen_heap_start: f4148000
(XEN) Init boot pages: 0x1d8 - 0x400.
(XEN) Init boot pages: 0x800 - 0x7f708000.
(XEN) Init boot pages: 0x7fe58000 - 0x7feb8000.
(XEN) Init boot pages: 0x1 - 0x1c000.
(XEN) Init boot pages: 0x28000 - 0x2fd99b000.
(XEN) Init boot pages: 0x2fe806eb0 - 0x2fedec010.
(XEN) Init boot pages: 0x2fedec070 - 0x2fedeff59.
(XEN) Init boot pages: 0x2fedeffc7 - 0x2fedf3000.
(XEN) Init boot pages: 0x2fef319d4 - 0x2fef4e010.
(XEN) Init boot pages: 0x2fef4ea00 - 0x2ffe14000.
(XEN) Init boot pages: 0x2ffe8 - 0x2fffb8000.
(XEN) System RAM: 8166MB (8362688kB)
(XEN) size of virtual frame_table: 20480kB
(XEN) virtual machine to physical table: f3a00090 size: 4144kB
(XEN) max_page: 0xbffee
(XEN) Xen heap: 62MB (64224kB)
(XEN) ACPI: RSDP (v002 INTEL ) @
0x7ff0c000
(XEN) ACPI: XSDT (v001 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @
0x7ff0c090
(XEN) ACPI: FADT (v003
Re: [Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0
Hi, Isaku and Tristan Thank you for your comments. On Thu, Oct 05, 2006 at 04:55:07PM +0900, Isaku Yamahata wrote: On Thu, Oct 05, 2006 at 04:00:20PM +0900, Akio Takebe wrote: Hi, Also in the case of current Xen-ia64-unstable(cset:11721), this panic is occured by specified dom0_mem=4G. (without my patch) I think the following error message is hint of this bug. (XEN) Warning: UC to WB for mpaddr=f9ff I checked the arch/ia64/xen/mm.c Why changing pteval2 from UC to WB is OK? If pteval2 is WB and pteval is UC, should pteval2 be changed to UC? Because it's RAM. not I/O. From your log (XEN) dom mem: type= 7, attr=0x0008, range= [0x8000-0xfe00) (2016MB) Probably ioremap hypercall failed. Please check it by adding debug message assign_domain_same_page(). I suppose it should complain somehow. The warning message is the result of Linux tries to use the addresses for I/O which is RAM. Then the next question is why/how Linux decided to use the addresses to map I/O. iomem_resource manages those regions so that such a overlap shouldn't happen. This is wrong. Linux doesn't complain. Dom0 builder assigns RAM which overlaps with PCI I/O so that dom0Linux can't access PCI devices. So far no one has assigned so much memory to dom0, this wasn't an issue. Thank you for your infomation!. I checked Linux /proc/iomem. You are right. # cat /proc/iomem [snip..] f8e0-f8ef : :06:02.1 f8fc-f8fc : :06:02.0 f8fd-f8fd : :06:02.0 f8fe-f8fe : :06:02.1 f8ff-f8ff : :06:02.1 f900-fbff : PCI Bus :00 ---this f9ff-f9ff03ff : :00:1d.7 f9ff-f9ff03ff : ehci_hcd fa00-fbff : PCI Bus #01 fa00-faff : :01:01.0 And the below is dom0 map at dom0_mem=2G and dom0_mem=4G. dom0_mem=4G (XEN) dom mem: type=13, attr=0x8008, range=[0x-0x1000) (4KB) (XEN) dom mem: type=10, attr=0x8008, range=[0x1000-0x2000) (4KB) (XEN) dom mem: type= 6, attr=0x8008, range=[0x2000-0x3000) (4KB) (XEN) dom mem: type= 7, attr=0x0009, range=[0x3000-0x7000) (16KB) (XEN) dom mem: type= 7, attr=0x0009, range=[0x7000-0x9000) (8KB) (XEN) dom mem: type= 7, attr=0x0009, range=[0x9000-0x00082000) (484KB) (XEN) dom mem: type= 6, attr=0x8009, range=[0x00082000-0x00084000) (8KB) (XEN) dom mem: type= 7, attr=0x0009, range=[0x00084000-0x00085000) (4KB) (XEN) dom mem: type= 7, attr=0x0009, range=[0x00085000-0x000a) (108KB) (XEN) dom mem: type= 5, attr=0x8009, range=[0x000c-0x0010) (256KB) (XEN) dom mem: type= 7, attr=0x0008, range=[0x0010-0x7f708000) (2038MB) (XEN) dom mem: type= 5, attr=0x8009, range=[0x7f70a000-0x7fb0) (3MB) (XEN) dom mem: type= 7, attr=0x0008, range=[0x7fb0-0x7fe0) (3MB) (XEN) dom mem: type= 5, attr=0x8009, range=[0x7fe0-0x7fe58000) (352KB) (XEN) dom mem: type= 7, attr=0x0008, range=[0x7fe58000-0x7feb8000) (384KB) (XEN) dom mem: type= 6, attr=0x8009, range=[0x7feba000-0x8000) (1MB) (XEN) dom mem: type= 7, attr=0x0008, range=[0x8000-0xfe00) (2016MB) (XEN) dom mem: type=11, attr=0x0001, range=[0xfe00-0xff00) (16MB) (XEN) dom mem: type= 6, attr=0x8001, range=[0xff00-0x0001) (16MB) (XEN) dom mem: type= 6, attr=0x8009, range=[0x0001e000-0x0002) (8KB) (XEN) dom mem: type= 5, attr=0x8009, range=[0x0002ffe14000-0x0002ffe8) (432KB) (XEN) dom mem: type= 6, attr=0x8009, range=[0x0002fffb8000-0x0003) (288KB) (XEN) dom mem: type=11, attr=0x8001, range=[0x0800-0x0c00) (64MB) (XEN) dom mem: type=12, attr=0x8001, range=[0x0c00-0x1000) (64MB) dom0_mem=2G (XEN) dom mem: type=13, attr=0x8008, range=[0x-0x1000) (4KB) (XEN) dom mem: type=10, attr=0x8008, range=[0x1000-0x2000) (4KB) (XEN) dom mem: type= 6, attr=0x8008, range=[0x2000-0x3000) (4KB) (XEN) dom mem: type= 7, attr=0x0009, range=[0x3000-0x7000) (16KB) (XEN) dom mem: type= 7, attr=0x0009, range=[0x7000-0x9000) (8KB) (XEN) dom mem: type= 7, attr=0x0009, range=[0x9000
Re: [Xen-ia64-devel] [Patch][RFC] allocate all memory to dom0
Hi, Isaku and Yoshi I'm sorry, I misread Isaku's mail. modular vnif(and xenblk) had two problem. 1. Allocating big order pages by using alloc_page(). This issue is no problem when vnif is not module, because the alloc_page() success at very early boot time. But in the case of modular vnif, this issue is happened, because the fragmentation is happened at late boot time. Juan said Why does ia64 give only 512M to dom0 instead of doing the same as x86? So I made the allocate_allmemory.patch. Then I found this problem. 2. Don't work copy_from/to_user(). this issue is fixed by Tristan's xencomm patches. This allocation problem is not relevant to copy_from/to_user problem. This issue is not happened again because Tristan's patches was merged. Best Regards, Akio Takebe Akio, Isaku The original motivation is to get modular vnif work. Now xencomm has been merged, this isn't an issue anymore. Akio, Is this right? Yes, you are right. I have not tried to check modular vnif yet. But I have checked it with cset 11635 + Tristan's xen-xcom-[a-c]3. diffs. The results is good work. I'm a bit confused. I thought Akio's issue is related to vnif backend's allocation failure (order=8 request), so, I don't understand why xencom patch resolved the issue. Could you explain why?, sorry for my ignorance. Thanks, Yoshi Akio Takebe [EMAIL PROTECTED] wrote： Hi, Isaku and Tristan Thank you for your comments. On Thu, Oct 05, 2006 at 04:55:07PM +0900, Isaku Yamahata wrote: On Thu, Oct 05, 2006 at 04:00:20PM +0900, Akio Takebe wrote: Hi, Also in the case of current Xen-ia64-unstable(cset:11721), this panic is occured by specified dom0_mem=4G. (without my patch) I think the following error message is hint of this bug. (XEN) Warning: UC to WB for mpaddr=f9ff I checked the arch/ia64/xen/mm.c Why changing pteval2 from UC to WB is OK? If pteval2 is WB and pteval is UC, should pteval2 be changed to UC? Because it's RAM. not I/O. From your log (XEN) dom mem: type= 7, attr=0x0008, range= [0x8000-0xfe00) (2016MB) Probably ioremap hypercall failed. Please check it by adding debug message assign_domain_same_page(). I suppose it should complain somehow. The warning message is the result of Linux tries to use the addresses for I/O which is RAM. Then the next question is why/how Linux decided to use the addresses to map I/O. iomem_resource manages those regions so that such a overlap shouldn't happen. This is wrong. Linux doesn't complain. Dom0 builder assigns RAM which overlaps with PCI I/O so that dom0Linux can't access PCI devices. So far no one has assigned so much memory to dom0, this wasn't an issue. Thank you for your infomation!. I checked Linux /proc/iomem. You are right. # cat /proc/iomem [snip..] f8e0-f8ef : :06:02.1 f8fc-f8fc : :06:02.0 f8fd-f8fd : :06:02.0 f8fe-f8fe : :06:02.1 f8ff-f8ff : :06:02.1 f900-fbff : PCI Bus :00 ---this f9ff-f9ff03ff : :00:1d.7 f9ff-f9ff03ff : ehci_hcd fa00-fbff : PCI Bus #01 fa00-faff : :01:01.0 And the below is dom0 map at dom0_mem=2G and dom0_mem=4G. dom0_mem=4G (XEN) dom mem: type=13, attr=0x8008, range= [0x-0x1000) (4KB) (XEN) dom mem: type=10, attr=0x8008, range= [0x1000-0x2000) (4KB) (XEN) dom mem: type= 6, attr=0x8008, range= [0x2000-0x3000) (4KB) (XEN) dom mem: type= 7, attr=0x0009, range= [0x3000-0x7000) (16KB) (XEN) dom mem: type= 7, attr=0x0009, range= [0x7000-0x9000) (8KB) (XEN) dom mem: type= 7, attr=0x0009, range= [0x9000-0x00082000) (484KB) (XEN) dom mem: type= 6, attr=0x8009, range= [0x00082000-0x00084000) (8KB) (XEN) dom mem: type= 7, attr=0x0009, range= [0x00084000-0x00085000) (4KB) (XEN) dom mem: type= 7, attr=0x0009, range= [0x00085000-0x000a) (108KB) (XEN) dom mem: type= 5, attr=0x8009, range= [0x000c-0x0010) (256KB) (XEN) dom mem: type= 7, attr=0x0008, range= [0x0010-0x7f708000) (2038MB) (XEN) dom mem: type= 5, attr=0x8009, range= [0x7f70a000-0x7fb0) (3MB) (XEN) dom mem: type= 7, attr=0x0008, range= [0x7fb0-0x7fe0) (3MB) (XEN) dom mem: type= 5, attr=0x8009, range= [0x7fe0-0x7fe58000) (352KB) (XEN) dom mem: type= 7, attr=0x0008, range= [0x7fe58000-0x7feb8000) (384KB) (XEN) dom mem: type= 6, attr
Re: [Xen-ia64-devel] crash on xen-ia64-unstable 11810:fcd746cf4647
Hi, Aron Do you use FC6? If so, it's compiler issue. Please see the following link. I posted a patch to fix it. https://www.redhat.com/archives/fedora-ia64-list/2006-August/msg00059.html Best Regards, Akio Takebe Unfortunately fixing the xen/xenlinux mismatch didn't solve the problem... Xen version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 4.1.1 20060828 (Red Hat 4.1.1-20)) Tue Oct 17 09:43:08 EDT 2006 Latest ChangeSet: Mon Oct 16 22:44:25 2006 -0400 11811:e06634ca24f6 (XEN) Xen command line: (XEN) xen image pstart: 0x400, xenheap pend: 0x800 (XEN) Xen patching physical address access by offset: 0x0 (XEN) find_memory: efi_memmap_walk returns max_page=103ffef (XEN) Before xen_heap_start: f4139e58 (XEN) After xen_heap_start: f4348000 (XEN) warning: skipping physical page 0 (XEN) Init boot pages: 0x4000 - 0x400. (XEN) Init boot pages: 0x800 - 0x3f5e4000. (XEN) Init boot pages: 0x3fb0 - 0x3fb2c000. (XEN) Init boot pages: 0x404000 - 0x40fcb51000. (XEN) Init boot pages: 0x40fd9b3d00 - 0x40fdf8c008. (XEN) Init boot pages: 0x40fdf8c068 - 0x40fdf8ffdf. (XEN) Init boot pages: 0x40fdf90008 - 0x40fef98008. (XEN) Init boot pages: 0x40fef986f8 - 0x40ffd68000. (XEN) Init boot pages: 0x40ffda4000 - 0x40ffe1. (XEN) Init boot pages: 0x40ffe8 - 0x40fffbc000. (XEN) System RAM: 4085MB (4183168kB) (XEN) size of virtual frame_table: 10288kB (XEN) virtual machine to physical table: f3fff7e00088 size: 2096kB (XEN) max_page: 0x103ffef (XEN) Xen heap: 60MB (62176kB) (XEN) ACPI: RSDP (v002 HP) @ 0x3fb2e000 (XEN) ACPI: XSDT (v001 HP rx2600 0x HP 0x) @ 0x3fb2e02c (XEN) ACPI: FADT (v003 HP rx2600 0x HP 0x) @ 0x3fb36800 (XEN) ACPI: SPCR (v001 HP rx2600 0x HP 0x) @ 0x3fb36938 (XEN) ACPI: DBGP (v001 HP rx2600 0x HP 0x) @ 0x3fb36988 (XEN) ACPI: MADT (v001 HP rx2600 0x HP 0x) @ 0x3fb36a48 (XEN) ACPI: SPMI (v004 HP rx2600 0x HP 0x) @ 0x3fb369c0 (XEN) ACPI: CPEP (v001 HP rx2600 0x HP 0x) @ 0x3fb36a10 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33870 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33a50 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33da0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb347c0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb351e0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb35c00 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb36620 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb36710 (XEN) ACPI: DSDT (v001 HP rx2600 0x0007 INTL 0x02012044) @ 0x (XEN) SAL 3.1: HP version 2.31 (XEN) SAL Platform features: None (XEN) SAL: AP wakeup using external interrupt vector 0xff (XEN) No logical to physical processor mapping available (XEN) avail:0x1180c600, status:0x600,control: 0x1180c000, vm?0x0 (XEN) No VT feature supported. (XEN) cpu_init: current=f40e (XEN) vhpt_init: vhpt paddr=0x40fcb4, end=0x40fcb4 (XEN) ACPI: Local APIC address e800fee0 (XEN) ACPI: LAPIC_ADDR_OVR (address[fee0]) (XEN) ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00] lsapic_eid[0x00] enabled) (XEN) CPU 0 (0x) enabled (BSP) (XEN) ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0x01] lsapic_eid[0x00] enabled) (XEN) CPU 1 (0x0100) enabled (XEN) ACPI: IOSAPIC (id[0x0] address[fed20800] gsi_base[16]) (XEN) ACPI: IOSAPIC (id[0x1] address[fed22800] gsi_base[27]) (XEN) ACPI: IOSAPIC (id[0x2] address[fed24800] gsi_base[38]) (XEN) ACPI: IOSAPIC (id[0x3] address[fed26800] gsi_base[49]) (XEN) ACPI: IOSAPIC (id[0x4] address[fed28800] gsi_base[60]) (XEN) ACPI: IOSAPIC (id[0x6] address[fed2c800] gsi_base[71]) (XEN) 2 CPUs available, 2 CPUs total (XEN) MCA related initialization done (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) CPU 0: base freq=200.000MHz, ITC ratio=13/2, ITC freq=1300.000MHz+/- 650ppm (XEN) Time init: (XEN) System Time: 18750245ns (XEN) scale: C4EC4EC4 (XEN) Boot processor id 0x0/0x0 (XEN) num_online_cpus=1, max_cpus=64 (XEN) cpu_init: current=f7ff (XEN) vhpt_init: vhpt paddr=0x40fef8, end=0x40fef8 (XEN) CPU 1: synchronized ITC with CPU 0 (last diff -13 cycles, maxerr 604 cycles) (XEN) CPU 1: base freq=200.000MHz, ITC ratio=13/2, ITC freq=1300.000MHz+/- 650ppm (XEN) Brought up 2 CPUs (XEN) Total of 2 processors activated (0.52 BogoMIPS). (XEN) Maximum number of domains: 63; 18 RID bits per domain (XEN) GSI 34 (edge, high) - CPU 0 (0x) vector 48 (XEN
Re: [Xen-ia64-devel] crash on xen-ia64-unstable 11810:fcd746cf4647
Hi, Aron and Alex It may be so, we need to add the patch into patches/ directory. I had thought xen-ia64-unstable was not needed because it was linux kernel problem. Alex, do you also think necessry? I can post the new patch. Best Regards, Akio Takebe Akio Takebe wrote: [Tue Oct 17 2006, 05:19:06PM EDT] Hi, Aron Do you use FC6? If so, it's compiler issue. Please see the following link. I posted a patch to fix it. https://www.redhat.com/archives/fedora-ia64-list/2006-August/msg00059.html Thanks Akio, that was the problem. I switched to a Gentoo compiler and the problem went away. I wonder if the patch should be applied to xen-ia64-unstable.hg even though it is already fixed in linux-2.6.18. The eventual merge should be easy, and it enables Fedora users to work with xen-ia64-unstable bits. What do you think? Regards, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] crash on xen-ia64-unstable 11810:fcd746cf4647
Hi, Alex Yes, you're right. Best Regards, Akio Takebe On Wed, 2006-10-18 at 07:07 +0900, Akio Takebe wrote: Hi, Aron and Alex It may be so, we need to add the patch into patches/ directory. I had thought xen-ia64-unstable was not needed because it was linux kernel problem. Alex, do you also think necessry? I can post the new patch. Hi Akio, I've heard of several people hitting this problem now, so I'd be willing to take a backport of the upstream linux-ia64 patch. I assume we just need the ia64/kernel/Makefile and ia64/kernel/gate.lds.S changes from this patch, right? http://www.kernel.org/hg/linux-2.6/?cs=dfbee33b0693 Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Fedora-ia64-list] [FYI] FC6 kernel and latest xen
Hi, Aron and Juan We fix this bug. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204011 Please apply the following patch. http://xenbits.xensource.com/xen-unstable.hg?cs=797430d25f1b Best Regards, Akio Takebe Hi, Prarit I enter BZ. Bugzilla Bug 204011: kernel unaligned access Best Regards, Akio Takebe Akio Takebe wrote: [EMAIL PROTECTED] ~]# kernel unaligned access to 0xe000187a4e1e, ip= 0xa001004fad50 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fae21 Akio, these are caused by the kernel making unaligned accesses to memory. Please enter a BZ against these and we'll try to track them down. P. kernel unaligned access to 0xe000187a4e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a4e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xe0001662921e, ip=0xa001004fad50 kernel unaligned access to 0xe0001662921e, ip=0xa001004fae21 kernel unaligned access to 0xe0001662921e, ip=0xa001004faed0 kernel unaligned access to 0xe0001662922e, ip=0xa001004fb130 kernel unaligned access to 0xe0001662921e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a5e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xedf1a61e, ip=0xa001004fad50 kernel unaligned access to 0xedf1a61e, ip=0xa001004fae21 kernel unaligned access to 0xedf1a61e, ip=0xa001004faed0 kernel unaligned access to 0xedf1a62e, ip=0xa001004fb130 kernel unaligned access to 0xedf1a61e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a501e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a501e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a501e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a502e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a501e, ip=0xa001004fb2e0 Best Regards, Akio Takebe -- Fedora-ia64-list mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/fedora-ia64-list -- Fedora-ia64-list mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/fedora-ia64-list -- Fedora-ia64-list mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/fedora-ia64-list ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] sync_console in ia64_init_handler
Hi, This patch fix the following issue. 1. boot xen 2. push INIT bottun 3. Nothing is printed to serial console. I add console_start_sync() into ia64_init_handler(). Then this issue is fixed. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] diff -r 06ed19691f6d xen/arch/ia64/linux-xen/mca.c --- a/xen/arch/ia64/linux-xen/mca.c Tue Oct 17 15:49:05 2006 -0600 +++ b/xen/arch/ia64/linux-xen/mca.c Thu Oct 19 14:49:59 2006 +0900 @@ -80,6 +80,7 @@ #ifdef XEN #include xen/symbols.h #include xen/mm.h +#include xen/console.h #endif #if defined(IA64_MCA_DEBUG_INFO) @@ -1240,6 +1241,7 @@ ia64_init_handler (struct pt_regs *pt, s */ ms = (pal_min_state_area_t *)(ia64_sal_to_os_handoff_state. pal_min_state | (6ul61)); #else + console_start_sync(); /* Xen virtual address in region 7. */ ms = __va((pal_min_state_area_t *)(ia64_sal_to_os_handoff_state [cpu].pal_min_state)); #endif Best Regards, Akio Takebe init_handler_console_sync.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] Guest PAL_INIT support for IPI
Hi, Wing I'm sorry. Our patch modify codes of hypervisor and dom0 kernel. So after installing xen.gz and dom0 kernel, please reboot system with them. Best Regards, Akio Takebe Oh, I forgot restart xend last time. But this time I get another error info. See attachment Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006年11月7日 14:55 To: Zhang, Xing Z; Masaki Kanno; xen-ia64-devel@lists.xensource.com Cc: Akio Takebe Subject: RE: [Xen-ia64-devel] [Patch] Guest PAL_INIT support for IPI Hi, Wing Could you try it again after xend stop; xend start. Best Regards, Akio Takebe New GFW will release soon, I think it's today. I used your merge.patch but failed. Seems some problems in python code. Attachment is a picture show the issue Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006年11月7日 13:39 To: Zhang, Xing Z; Masaki Kanno; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Patch] Guest PAL_INIT support for IPI Hi, Wing I don't know, but if you give me newer GFW, we'll test xm os-init on windows of domVTi. Best Regards, Akio Takebe I still have a question: How windows OS_INIT handler do? How can I confirm whether PAL_INIT executed successful in windows? ( in Linux , I can see a lot of dump info on screen) Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation -Original Message- From: Masaki Kanno [mailto:[EMAIL PROTECTED] Sent: 2006ト・1ヤツ6ネユ 18:18 To: Zhang, Xing Z; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [Patch] Guest PAL_INIT support for IPI Hi Zhang, We were looking forward to your patches. We have a question and a comment. Question: How can we inject the INIT interrupt into domVTi? We made xm os-init command, and tested your patch. But INIT handler of domVTi was not executed, we think. We attach two files. - merge.patch : It is a patch that we tested. - xenctx.log : It is a cpu-context of domVTi after we test. Comment: We think that TODO line is unnecessary. @@ -404,7 +419,7 @@ static void deliver_ipi (VCPU *vcpu, uin break; case 5: // INIT // TODO -- inject guest INIT-- This! -panic_domain (NULL, Inject guest INIT!\n); +vmx_inject_guest_pal_init(vcpu); break; case 7: // ExtINT vmx_vcpu_pend_interrupt (vcpu, 0); Best regards, Kan and Akio This patch add guest PAL_INIT support for IPI Signed-off-by, Zhang Xin [EMAIL PROTECTED] Good good study,day day up ! ^_^ -Wing(zhang xin) 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 mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] remove ASSERT in vmx_init.c
Hi, I forgot removing unnecessary ASSERT() when I fixed vmx_build_physmap_table(). Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe unnecessary_assert_vmx_build.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] Support big endian domU's
Hi, Dietmar
I started with supporting big endian domU's on ia64 and have some questions.
I did some changes to tools/libxc/xc_load_elf.c and now I can load and start
the big endian domU.
Because this is some sort of a new branch in load_elf how can I get in
changes? Should I simply send patches to x86 list or should I first initiate
a discussion about that?
Is the changes related to x86?
If so, we should discuss on xen-devel.
I added a flag is_be to struct arch_domain. Is this ok, or may this produce
some problems?
struct arch_domain {
struct mm_struct mm;
/* Flags. */
union {
unsigned long flags;
struct {
unsigned int is_vti : 1;
#ifdef CONFIG_XEN_IA64_PERVCPU_VHPT
unsigned int has_pervcpu_vhpt : 1;
#endif
unsigned int is_be : 1;
};
};
I feel like this is ok, but you may add __attribute__((aligned(8))).
Should I introduce a new compiler flag where the special big endion support
can be switched off?
Yes,I think so.
Isaku often introduce new flags, I like the way. :)
A question to the function reflect_interruptions() in fault.c:
As far as I understand the code, PSCB(...) are prepared to contain the
trapped
dumU environment..
regs-... are prepared to contain the environment for return to the trap
handler of the domU.
If this is the case then on a big endian domU the psr.be bit ist not set in
regs-ipsr from dcr.be. This is needed on return from Xen to the trap handler
of the domU.
The other thing is that in vcpu_get_ipsr_int_state() the psr.be bit should
not
be overwritten by dcr.be. There are cases where a big endian domU runs
temporarily littlen endian (during efi calls, ...). If there would be a trap,
it would return with psr.be = 1, which is not what we want.
The same problem may occur on reflect_event()!
I don't understand this issue very much.
But can you check is_be flags, and restore psr.be in each cases?
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] xen/ia64 kernel BUG while rebooting
Hi, I'm debugging the following Bugzilla now. RH Bugzilla#203032: xen/ia64 kernel BUG while rebooting https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203032 RHEL5beta and FC6 still show the CallTrace while rebooting. I check why it is shown. I found thd CallTrace is not shown if we reboot after doing the below. # /etc/xen/scripts/network-bridge stop I think it should be happened also by using source of xen-ia64-unstable. (not RH source) But e1000_shutdown() is not called when I use source of xen-ia64-unstable. I don't know why yet. I'll continue to debug it. If you have comments, please tell me. 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] [Q]ltrace and do_ssc
Hi, This issue is strange. Why do codes of hpsim is used? Best Regards, Akio Takebe Hi, Alex I am trying ltrace ps on IA64. It makes dom0 hung. From the serial console messages, (XEN) ia64_handle_break: bad ssc code 4001c480, iip= 0x40002140, b0=0x40002380... spinning It seems come from following system call. [EMAIL PROTECTED]/arch/ia64/hp/sim/hpsim.S Do you have any idea to solve this problem? Thanks Atsushi SAKAI ___ 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 warnings while rebooting
Hi, Aron
Hi Akio,
I'm sorry, but I'm confused by your message. Are you saying there are
two problems here? One problem in xen/ia64 and one problem in the
e1000 driver?
Yes, there are two problem here.
1. double free message is happened
2. CallTrace is happened
problem 1 is a issue of free_irq_vector.
My patch fix this problem.
problem 2 is a issue of some network drivers.
suspend handlers of e1000, tg3 and so on are not called free_irq().
free_irq() is called by only close handlers of them.
So if close handlers are not called before suspend handlers,
iosapic_unregister_intr() call WARN_ON(1).
iosapic_unregister_intr (unsigned int gsi)
{
unsigned long flags;
int irq, vector, index;
[snip...]
memset(iosapic_intr_info[vector], 0,
sizeof(struct iosapic_intr_info));
iosapic_intr_info[vector].low32 |= IOSAPIC_MASK;
INIT_LIST_HEAD(iosapic_intr_info[vector].rtes);
if (idesc-action) {
printk(KERN_ERR
interrupt handlers still exist on
IRQ %u\n, irq);
WARN_ON(1); HERE!!
}
/* Free the interrupt vector */
free_irq_vector(vector);
}
[snip...]
}
I think there are three solutions.
A. do # /etc/xen/scripts/network-bridge stop before reboot
I think this is the best solution. But if we do that, where is better?
/etc/init.d/network or /etc/init.d/xend?
And How do we do in the case of routing mode?
B. apply the e1000 patch(I think other driver also apply likely patch.)
I think the better solution.
But I'm not familiar with e1000 driver.
So I'd like to review it by RH Engineer and community people.
The patch is the below.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=edd106fc8ac1826dbe231b70ce0762db24133e5c;hp=e78181feb0b94fb6afeaef3b28d4f5df1b847c98
C. ifdef the WARN_ON(1) in iosapic_unregister_intr.
This is the easiest solution.
And because Xen don't do I/O Hotplug, this may be the best.
You sent a patch, I guess that is for xen-ia64-unstable, right? If
that is ready to be applied, could you include a description of the
problem and what the patch does?
Yes, my patch is for xen-ia64-unstable.
My patch fix problem 1 (double free messages).
I already have patches for RHEL5 beta.
I'll send you soon if my patch is applied in xen-ia64-unstable.
- Bug escription
Please see the following two functions.
assign_irq_vector() is para-virulized, free_irq_vector() is not
para-virtualized.
So ia64_vector_mask is not used in dom0 kernel.
Though free_irq_vector() try to clear ia64_vector_mask in dom0 kernel,
ia64_vector_mask is always zero, so the double free message is happened.
int
assign_irq_vector (int irq)
{
int pos, vector;
#ifdef CONFIG_XEN
if (is_running_on_xen()) {
extern int xen_assign_irq_vector(int);
return xen_assign_irq_vector(irq);
}
#endif
again:
pos = find_first_zero_bit(ia64_vector_mask, IA64_NUM_DEVICE_VECTORS);
vector = IA64_FIRST_DEVICE_VECTOR + pos;
if (vector IA64_LAST_DEVICE_VECTOR)
return -ENOSPC;
if (test_and_set_bit(pos, ia64_vector_mask))
goto again;
return vector;
}
void
free_irq_vector (int vector)
{
int pos;
if (vector IA64_FIRST_DEVICE_VECTOR || vector
IA64_LAST_DEVICE_VECTOR)
return;
pos = vector - IA64_FIRST_DEVICE_VECTOR;
if (!test_and_clear_bit(pos, ia64_vector_mask))
printk(KERN_WARNING %s: double free!\n, __FUNCTION__);
HERE
}
- What the patch does?
I do that free_irq_vector() is para-virtualized.
Regarding the e1000 bug, could you comment in the RH bug?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208599
Yes.
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] fix warnings while rebooting
Hi, Alex Unfortunately I've found a problem with this patch since committing it. My system has a 2 port e1000 card that shows up as PCI devices :01:02.0 and :01:02.1. I hide function 1 from dom0 using pciback.hide=(:01:02.1). Without trying to start up any guest domains, on reboot dom0 dies with the NaT consumption fault shown below. This is curious. free_irq_vector() is called at shutdown handler. But this notifier_call_chain is called before shutdown handler. Hmmm... I'll investigate it. Could you send me the result of lspci -vv on your system? I've disabled the Xen call to free_irq_vector() until we can figure out what's going wrong. Thanks, Thanks. Isn't this issue occurred by using your patch? reboot[2702]: NaT consumption 17179869216 [1] Modules linked in: Pid: 2702, CPU 0, comm: reboot psr : 0010085a6010 ifs : 8309 ip : [a001000ac9b0] Not tainted ip is at notifier_call_chain+0x30/0xc0 isr(17179869216 = 0x40020) show Data NaT Page Consumption. The below is disassemble of notifier_call_chain(). r32 is pointer of notifier_block list. I'll check it first. a001000ac760 notifier_call_chain: a001000ac760: 00 20 25 0c 80 05 [MII] alloc r36=ar.pfs,9,6,0 a001000ac766: 30 02 00 62 00 a0 mov r35=b0 a001000ac76c: 04 08 00 84 mov r37=r1 a001000ac770: 11 00 01 40 18 10 [MIB] ld8 r32=[r32] a001000ac776: 80 00 00 00 42 00 mov r8=r0 a001000ac77c: 00 00 00 20 nop.b 0x0;; a001000ac780: 10 00 00 00 01 00 [MIB] nop.m 0x0 a001000ac786: 60 00 80 0e 72 03 cmp.eq p6,p7=0,r32 a001000ac78c: 80 00 00 43 (p06) br.cond.dpnt.few a001000ac800 notifier_call_chain+0xa0 a001000ac790: 08 00 00 00 01 00 [MMI] nop.m 0x0 a001000ac796: 80 00 80 30 20 c0 ld8 r8=[r32] HERE??? a001000ac79c: 04 00 01 84 mov r38=r32 a001000ac7a0: 09 38 01 42 00 21 [MMI] mov r39=r33 a001000ac7a6: 80 02 88 00 42 00 mov r40=r34 a001000ac7ac: 84 00 01 84 adds r32=8,r32;; a001000ac7b0: 0a 70 20 10 18 14 [MMI] ld8 r14=[r8],8;; a001000ac7b6: 00 00 00 02 00 c0 nop.m 0x0 a001000ac7bc: e0 08 00 07 mov b6=r14 a001000ac7c0: 13 08 00 10 18 10 [MBB] ld8 r1=[r8] a001000ac7c6: 00 00 00 00 10 00 nop.b 0x0 a001000ac7cc: 68 00 80 10 br.call.sptk.many b0=b6;; a001000ac7d0: 10 00 00 00 01 00 [MIB] nop.m 0x0 a001000ac7d6: 80 f0 20 12 28 00 tbit.z p8,p9=r8,15 a001000ac7dc: 00 00 00 20 nop.b 0x0 a001000ac7e0: 1c 08 00 4a 00 21 [MFB] mov r1=r37 a001000ac7e6: 00 00 00 02 80 04 nop.f 0x0 a001000ac7ec: 20 00 00 43 (p09) br.cond.dpnt.few a001000ac800 notifier_call_chain+0xa0 a001000ac7f0: 12 00 01 40 18 10 [MBB] ld8 r32=[r32] a001000ac7f6: 00 00 00 00 10 00 nop.b 0x0 a001000ac7fc: 90 ff ff 48 br.few a001000ac780 notifier_call_chain+0x20 a001000ac800: 10 00 00 00 01 00 [MIB] nop.m 0x0 a001000ac806: 00 18 05 80 03 00 mov b0=r35 a001000ac80c: 00 00 00 20 nop.b 0x0 a001000ac810: 11 00 00 00 01 00 [MIB] nop.m 0x0 a001000ac816: 00 20 01 55 00 80 mov.i ar.pfs=r36 a001000ac81c: 08 00 84 00 br.ret.sptk.many b0;; 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] Reserved Register/Field fault not correct handledin Xen?
Hi, Dietmar
Hi Akio,
I think your suggestion is almost right.
But should the folloing IA64_ISR_CODE_LFETCH be checked?
(because Privilege Register Fault may be occurred on guest.)
ia64_fault()
393 if ((isr IA64_ISR_NA)
394 ((isr IA64_ISR_CODE_MASK) == IA64_ISR_CODE_LFETCH)) {
395 /*
396 * This fault was due to lfetch.fault, set ed bit in
the 397 * psr to cancel the lfetch.
398 */
399 ia64_psr(regs)-ed = 1;
400 printk(ia64_fault: handled lfetch.fault\n);
401 return;
402 }
If the FAULT_OR_REFLECT(24) is called in the trap handler, than the domU has
to handle the lfetch.fault. and this is OK, I think.
So my suggestion should be OK?
I think more, and you are right.
I thought ia64_psr(regs)-ed = 1 on domU generate Privilege Register Fault
and General Exception is happended again.
But because xen check code=0x20, your suggestion is OK.
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] please test machvec+sn2 tree
Hi, Alex, Jes, and all I tested the machvec+sn2 tree on Tiger4(which is montecito machine) and PRIMEQUEST480(which is madison machine). I can boot dom0, up,smp-domU, up,smp-domVTI on Tiger4. And I can boot dom0, up,smp-domU on PRIMEQUEST480. I can run unixbench up-domU, up-domVTI on Tiger4 completely. The test changeset is #13075 of http://free.linux.hp.com/~awilliam/xen-ia64-machvec/. 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] dom0 memory not responding to changing dom0_mem
Hi, David My elilo.conf entry looks like this image=vmlinuz-2.6.16.33-xen0 label=2.6.16.33-xen0 vmm=xen-3.0-unstable.gz initrd=initrd-2.6.16.33-xen0.img read-only append=sync_console dom0_mem=262144 root=/dev/sda2 3 I've tried changing dom0_mem to 256M, 128M and the dom0 system keeps coming up with 453M of memory. We need to split options of xen and dom0 with --. So you should use like the following option. append=sync_console dom0_mem=262144 -- root=/dev/sda2 3 Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Crash-utility] crash version 4.0-3.15 is available
Hi, Dave The belows are great information for xen-ia64. We are happy because of starting support it. - Introduced support for xendumps of para-virtualized ia64 kernels. It should be noted that currently the ia64 Xen kernel does not lay down a switch_stack for the panic task, so only raw bt -t backtraces can be done on the panic task. ([EMAIL PROTECTED]) - Introduced support for xm save dumpfiles of para-virtualized ia64 kernels, which use a completely different format than that used for x86 and x86_64. ([EMAIL PROTECTED]) Can we use bt with xm save dumpfiles of para-virtualized ia64? Is xm save dumpfile better for crash-utils than xendump file? Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [patch] make Xen assign meta-physical memory in spaces that match real hardware
Hi, Jes Isaku work this issue now. Could you see his patches? http://lists.xensource.com/archives/html/xen-ia64-devel/2006-12/msg00249.html Best Regards, Akio Takebe Hi, This is an initial patch to make Xen start assigning meta physical memory in the physical ranges that match the hardware it is running upon. More work needs to be done in this area, but it is crucial we assign memory correctly, in particular for dom0. Cheers, Jes ---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] Re: [PATCH][RFC] fix dom0 builder TAKE3
, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt :00:1d.0[A] - GSI 16 (level, low) - IRQ 58
uhci_hcd :00:1d.0: UHCI Host Controller
uhci_hcd :00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd :00:1d.0: irq 58, io base 0x0d00
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
GSI 17 (level, low) - CPU 0 (0x) vector 59
ACPI: PCI Interrupt :00:1d.1[B] - GSI 17 (level, low) - IRQ 59
uhci_hcd :00:1d.1: UHCI Host Controller
uhci_hcd :00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd :00:1d.1: irq 59, io base 0x0d20
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
GSI 18 (level, low) - CPU 0 (0x) vector 60
ACPI: PCI Interrupt :00:1d.2[C] - GSI 18 (level, low) - IRQ 60
uhci_hcd :00:1d.2: UHCI Host Controller
uhci_hcd :00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd :00:1d.2: irq 60, io base 0x0d40
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
device-mapper: 4.5.0-ioctl (2005-10-04) initialised: [EMAIL PROTECTED]
EFI Variables Facility v0.08 2004-May-17
Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20
2006 UTC).
no UART detected at 0x1
specify port
snd_mpu401: probe of snd_mpu401.0 failed with error -22
ALSA device list:
#0: Dummy 1
#1: Virtual MIDI Card 1
NET: Registered protocol family 2
IP route cache hash table entries: 2097152 (order: 10, 16777216 bytes)
TCP established hash table entries: 1048576 (order: 10, 16777216 bytes)
TCP bind hash table entries: 65536 (order: 6, 1048576 bytes)
TCP: Hash tables configured (established 1048576 bind 65536)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Bridge firewalling registered
xen privcmd uses pseudo physical addr range [0x40d200, 0x300]
(3928784MB)
BUG at mm.c:1442
(XEN) FIXME: implement ia64 dump_execution_state()
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) BUG at mm.c:1442
(XEN)
(XEN)
(XEN) Reboot in five seconds...
Best Regards,
Akio Takebe
On Wed, Jan 03, 2007 at 09:02:05PM -0700, Alex Williamson wrote:
Thanks for continuing to work on this. These patches seem to work
fine for me, I booted with a 64GB dom0. Are there any known outstanding
issues with these patches (since they were sent as an RFC) or should we
add them to the tree? It would certainly be nice to remove the dom0
memory limitations. Thanks,
Thank you for testing with hp box.
Basically they should be commited except minor issues.
I used RFC because I can test those patches only with tiger4 and
I wasn't sure with other IA64 machines.
outstanding issues (AFAIK):
- fix_balloon_init.patch should be sent out to xen-devel because
it modifies common code. I'll sent it out today.
I don't think this is a big issue.
- revise default configurations.
xen/buildconfigs/
linux-defconfig_xen0_ia64
linux-defconfig_xenU_ia64
linux-defconfig_xen_ia64
probably CONFIG_VIRTUAL_MEM_MAP and
CONFIG_{FLATMEM, DISCONTIGMEM, SPARSEMEM}_MANUAL should be revised.
But I'm not very sure how they should be as default.
- test on BULL box?
If there is something bad with BULL box, we can solve it out later.
- BULL: no report yet.
- sgi altix: Jes Sorensen confirmed.
- hp: you confirmed.
- tiger4: I confirmed. I expect those patches are O.K. with tiger2
because tiger2 is very similar in memory mapping.
- domU(driver domain)
This is an another issues. This should be addressed as a different issue.
--
yamahata
___
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] [RFC] Change .config of dom0 for
Hi, Isaku and all When I boot dom0 with dom0_mem=31G, dom0 use about 2GB memory after booting. I check why dom0 use 2GB, then I found the following message at the boot time. Aperture: 64 megabytes Kernel range: 0xe52b4000 - 0xe92b4000 Address size: 30 bits Memory: 30649984k/32456704k available (10480k code, 1805472k reserved, 4361k data, 288k init) --- !!!reserved 1.8GB!!! McKinley Errata 9 workaround not needed; disabling it So I check the rsvd_memory, but rsvd_region is no problem. rsvd_region[0]=1480 (0xe0002228 - 0xe00027f0) rsvd_region[1]=96 (0xe100 - 0xe160) rsvd_region[2]=18344456 (0xe400 - 0xe517ea08) rsvd_region[3]=16384(0xe518 - 0xe5184000) rsvd_region[4]=66 (0xe5180080 - 0xe51800c2) rsvd_region[5]=80 (0xe5180480 - 0xe51804d0) rsvd_region[6]=1305615 (0xe5184000 - 0xe52c2c0f) rsvd_region[7]=0(0x - 0x) Because Isaku's dom0 patches change dom0's memory map from contiguous memory to discontiguous memory, I change .config of dom0 like the below, then I can get the following message and dom0 don't use 2GB. # diff -uNrp buildconfigs/linux-defconfig_xen_ia64 build-linux-2.6.16.33- xen_ia64/.config --- buildconfigs/linux-defconfig_xen_ia64 2007-01-17 07:21:06.0 + 0900 +++ build-linux-2.6.16.33-xen_ia64/.config 2007-01-17 20:22:11.0 + 0900 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.16.29-xen -# Tue Nov 14 10:38:50 2006 +# Linux kernel version: 2.6.16.33-xen +# Wed Jan 17 20:22:11 2007 # # @@ -125,18 +125,23 @@ CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # CONFIG_SCHED_SMT is not set # CONFIG_PREEMPT is not set CONFIG_SELECT_MEMORY_MODEL=y -CONFIG_FLATMEM_MANUAL=y -# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_FLATMEM_MANUAL is not set +CONFIG_DISCONTIGMEM_MANUAL=y # CONFIG_SPARSEMEM_MANUAL is not set -CONFIG_FLATMEM=y +CONFIG_DISCONTIGMEM=y CONFIG_FLAT_NODE_MEM_MAP=y +CONFIG_NEED_MULTIPLE_NODES=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_MIGRATION=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y -# CONFIG_VIRTUAL_MEM_MAP is not set +CONFIG_NUMA=y +CONFIG_VIRTUAL_MEM_MAP=y +CONFIG_HOLES_IN_ZONE=y +CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y # CONFIG_IA32_SUPPORT is not set CONFIG_IA64_MCA_RECOVERY=y CONFIG_PERFMON=y @@ -166,6 +171,7 @@ CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=y +CONFIG_ACPI_NUMA=y CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y @@ -1522,7 +1528,6 @@ CONFIG_HAVE_ARCH_ALLOC_SKB=y CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y CONFIG_XEN_BALLOON=y CONFIG_XEN_SKBUFF=y -# CONFIG_XEN_DEVMEM is not set CONFIG_XEN_REBOOT=y # CONFIG_XEN_SMPBOOT is not set CONFIG_XEN_INTERFACE_VERSION=0x00030203 @@ -1558,3 +1563,4 @@ CONFIG_XEN_COMPAT_030002_AND_LATER=y CONFIG_XEN_COMPAT_030002=y CONFIG_HAVE_IRQ_IGNORE_UNHANDLED=y CONFIG_NO_IDLE_HZ=y +CONFIG_XEN_DEVMEM=y Should we change .config of dom0? Or should we fix other code? I think we should change .confing, I use CONFIG_DISCONTIGMEM and CONFIG_VIRTUAL_MEM_MAP, but we may use SPARSEMEM. (I'll check SPARSEMEM soon.) Please comment. 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] [RFC] Change .config of dom0 for
Hi, Alex and all I think we should change .confing, I use CONFIG_DISCONTIGMEM and CONFIG_VIRTUAL_MEM_MAP, but we may use SPARSEMEM. (I'll check SPARSEMEM soon.) I agree, we're presenting dom0 with a memory map similar to bare metal hardware. The contiguous memory handlers aren't going to be able to deal with that efficiently on many ia64 platforms. Thanks, Thank you for your reply. I check SPARSEMEM, but unfortunately I have many compile error. So if we choice SPARSEMEM, we must fix bits. Which config are everyone think best? Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] allocate all memory to dom0
Hi,
If we don't specify dom0_mem, we can use all memory on dom0 with this patch.
I change alloc_dom0() to alloc_dom0_size(), and alloc_dom0_size() is static
function.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 1625e2ba02fcb2c7d162e178a045b7d540a213f1
# Parent a2b2b2a011f1d406d49caba478020f3b2b173cb8
allocate all memory to dom0, if we don't specify dom0_mem.
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
diff -r a2b2b2a011f1 -r 1625e2ba02fc xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cMon Jan 15 15:15:26 2007 -0700
+++ b/xen/arch/ia64/xen/domain.cThu Jan 18 13:45:00 2007 +0900
@@ -50,7 +50,7 @@
#include asm/tlb_track.h
#include asm/perfmon.h
-unsigned long dom0_size = 512*1024*1024;
+unsigned long dom0_size = 0;
/* dom0_max_vcpus: maximum number of VCPUs to create for dom0. */
static unsigned int dom0_max_vcpus = 1;
@@ -936,16 +936,24 @@ static void loaddomainelfimage(struct do
}
}
-void alloc_dom0(void)
-{
+static void alloc_dom0_size(void)
+{
+ unsigned long max_dom0_pages;
+
+ if ( dom0_size == 0 )
+ {
+ max_dom0_pages = avail_domheap_pages() -
min(avail_domheap_pages() / 16UL, 512UL (20 - PAGE_SHIFT)) ;
+ dom0_size = max_dom0_pages * PAGE_SIZE;
+ }
+
+ if (running_on_sim) {
+ dom0_size = 128*1024*1024; //FIXME: Should be configurable
+ }
+
/* Check dom0 size. */
if (dom0_size 4 * 1024 * 1024) {
panic(dom0_mem is too small, boot aborted
(try e.g. dom0_mem=256M or dom0_mem=65536K)\n);
- }
-
- if (running_on_sim) {
- dom0_size = 128*1024*1024; //FIXME: Should be configurable
}
/* no need to allocate pages for now
@@ -1008,6 +1016,8 @@ int construct_dom0(struct domain *d,
memset(dsi, 0, sizeof(struct domain_setup_info));
printk(*** LOADING DOMAIN 0 ***\n);
+
+ alloc_dom0_size();
max_pages = dom0_size / PAGE_SIZE;
d-max_pages = max_pages;
diff -r a2b2b2a011f1 -r 1625e2ba02fc xen/arch/ia64/xen/xensetup.c
--- a/xen/arch/ia64/xen/xensetup.c Mon Jan 15 15:15:26 2007 -0700
+++ b/xen/arch/ia64/xen/xensetup.c Thu Jan 18 13:45:00 2007 +0900
@@ -43,7 +43,6 @@ extern void early_setup_arch(char **);
extern void early_setup_arch(char **);
extern void late_setup_arch(char **);
extern void hpsim_serial_init(void);
-extern void alloc_dom0(void);
extern void setup_per_cpu_areas(void);
extern void mem_init(void);
extern void init_IRQ(void);
@@ -409,8 +408,6 @@ void start_kernel(void)
trap_init();
-alloc_dom0();
-
end_boot_allocator();
init_xenheap_pages(__pa(xen_heap_start), xenheap_phys_end);
Best Regards,
Akio Takebe
allocate_all_mem.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] allocate all memory to dom0
Hi, Alex Thank you for your comments. I agree, my patch can be applied after fixing .config(of discontigous issue), fixing and optimizing them, and so on. Also, as Mark said, xen-ia64 may not need to allocate all memory and cpu to dom0. IA64 machine is very large system, and dom0 don't need large machine environment. Best Regards, Akio Takebe On Thu, 2007-01-18 at 13:06 +0900, Akio Takebe wrote: Hi, If we don't specify dom0_mem, we can use all memory on dom0 with this patch. I change alloc_dom0() to alloc_dom0_size(), and alloc_dom0_size() is static function. Hi Akio, I don't think we're able to do this yet. One of my test systems is an rx6600 w/ 96G of memory. With this patch, I get a _very_ long pause during Xen boot (30 seconds), followed by an endless loop of page allocation failures: (XEN) Domain0 EFI passthrough: ACPI 2.0=0x3fdce000 SMBIOS=0x3e52a000 [long pause here] (XEN) Cannot handle page request order 0! (XEN) Cannot handle page request order 0! (XEN) Cannot handle page request order 0! (XEN) Cannot handle page request order 0! (XEN) Cannot handle page request order 0! ... The most memory I can specify for dom0_mem and still boot seems to be around 87G. Obviously failing to boot is bad, but the long pause while we're individually mapping every page for dom0 is also a usability issue. We either need to see about optimizing this code segment to reduce the delay to something acceptable, or add some kind of forward progress indicator. 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 0/2] INIT handler improvement
Hi, I fix a bug and I improve CallTrace at the time of pushing INIT button. This improve to support calltrace of all vcpu. [1/2] fix a bug init_handler_platform [2/2] improve calltarce Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch 0/1] fix a bug init_handler_platform
Hi, This patch fix breaking switch stack. unw_init_running() in INIT handler the save switch stack pointer. The swith stack is not guaranteed after returning unw_init_running(). But because INIT handler of Xen-ia64 call some functions after unw_init_running(), the switch stack is broken by the functions. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe fix_break_sw_init_hanlder.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 2/2] improve calltarce
Hi, I improve CallTrace at the time of pushing INIT button. This improve to support calltrace of all vcpu. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe improvement_init_handler.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] [RFC] dump core is failed for PAL_HALT
Hi, all
In linux side, panic() call smp_send_stop() before panic_notifier_list.
And smp_send_stop() call PAL_HALT.
So we cannot coredump guest memory,
because smp_send_stop call domain_shutdown(SHUTDOWN_poweroff).
Which way shold we choice?
A. we don't call smp_send_stop in panic()
B. we don't call PAL_HALT in xen_pal_emulator(),
and we call EFI_RESET_SYSTEM in machine_halt().
A is very easy and simple, but we must modify common code.
If we choice B, we must fix domain_shutdown() and machine_halt().
I think B is probably better, but are there anything else to fix?
In linux, panic() is the below.
59
60 NORET_TYPE void panic(const char * fmt, ...)
61 {
[snip...]
90 #ifdef CONFIG_SMP
91 /*
92 * Note smp_send_stop is the usual smp shutdown function, which
93 * unfortunately means it may not be hardened to work in a panic
94 * situation.
95 */
96 smp_send_stop();
97 #endif
98
99 atomic_notifier_call_chain(panic_notifier_list, 0, buf);
100
In xen, PAL_HALT is the below.
381 struct ia64_pal_retval
382 xen_pal_emulator(unsigned long index, u64 in1, u64 in2, u64 in3)
383 {
[snip...]
603 case PAL_HALT:
604 if (current-domain == dom0) {
605 printk (Domain0 halts the machine\n);
606 console_start_sync();
607 (*efi.reset_system)(EFI_RESET_SHUTDOWN,0,0,NULL);
608 }
609 else
610 domain_shutdown(current-domain,
SHUTDOWN_poweroff);
611 break;
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dump core is failed for PAL_HALT)
Hi, Isaku and all Thank you for your suggestion. Choice C. Modify PAL_HALT emulation as follows. If other vcpu is left and alive, vcpu is put in sleep. If current is the last vcpu, call domain_shutdown(SHUTDOWN_poweroff). It will be guaranteed that the vcpu which call panic() calls HYPERVISOR_shutdown(SHUTDOWN_crash) via xen_panic_block so that the guest domain's core dump should be created. (I haven't tested it though.) -- I make the patch of choice C. This patch modify PAL_HALT of guest domain. I can dump correctly with my patch. But if I use this patch, I cannot shutdown domU, because linux machine_halt() call cpu_halt from only one cpu. Do anyone know why linux call it from only one cpu? Or do I have miss-reading about that? Best Regards, Akio Takebe domainU_pal_halt.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dump core is failed for PAL_HALT)
Hi, Isaku and Tristan
Thank you for your comments.
Probably modifying machine_reboot() and machine_power_off()
needs modification(paravirtualization) to call shutdown hypercall.
I think all the paravirtualization can be done through EFI+PAL calls.
I fix by using notifier_call and I can shutdown domU.
But I don't try domVTi.
Must we be care about shutdown process of OSes on domVTi?
What do you think?
diff -r dc4a69e66104 linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Fri Jan 19 13:27:52
2007
+0900
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Wed Jan 24 19:27:09
2007
+0900
@@ -64,6 +64,7 @@
#ifdef CONFIG_XEN
#include asm/hypervisor.h
#include asm/xen/xencomm.h
+#include asm/kdebug.h
#endif
#include linux/dma-mapping.h
@@ -95,6 +96,19 @@ xen_panic_event(struct notifier_block *t
static struct notifier_block xen_panic_block = {
xen_panic_event, NULL, 0 /* try to go last */
+};
+
+static int
+xen_poweroff_event(struct notifier_block *this, unsigned long event, void *ptr)
+{
+ if ( event == DIE_MACHINE_HALT )
+ HYPERVISOR_shutdown(SHUTDOWN_poweroff);
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block xen_poweroff_block = {
+ xen_poweroff_event, NULL, 0 /* try to go last */
};
#endif
@@ -448,6 +462,7 @@ setup_arch (char **cmdline_p)
setup_xen_features();
/* Register a call for panic conditions. */
notifier_chain_register(panic_notifier_list, xen_panic_block);
+ notifier_chain_register(ia64die_chain, xen_poweroff_block);
}
#endif
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dump core is failed for PAL_HALT)
Hi, Probably modifying machine_reboot() and machine_power_off() needs modification(paravirtualization) to call shutdown hypercall. I think all the paravirtualization can be done through EFI+PAL calls. Do Linux/Windows-ia64 use ACPI to shutdown system? If so, we must not be care about VTi domain. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dump core is failed for PAL_HALT)
Hi, Tristan On Wed, Jan 24, 2007 at 07:29:14PM +0900, Akio Takebe wrote: Hi, Probably modifying machine_reboot() and machine_power_off() needs modification(paravirtualization) to call shutdown hypercall. I think all the paravirtualization can be done through EFI+PAL calls. Do Linux/Windows-ia64 use ACPI to shutdown system? Yes. If so, we must not be care about VTi domain. Yes. The issue araises in PV because ACPI is not used to shutdown the system. Thank you for your answer. I remake my patches, and I'll post soon. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)
Hi, Alex Thank you for your elaboration. I agree your opinion. So, for PV domains, cpu_halt() should just take the vcpu offline. I don't think there's any reason to special case the last vcpu going offline and shutdown the domain. That's not what real hardware does. Exactly. Machine restart/reboot should (and does) happen transparently when Xen catches the EFI call. To support poweroff, I think we should set pm_power_off to a Xen specific hypervisor shutdown routine. The abstraction is already in place to do this. OK, I'll try it. Do VTI domains implement enough ACPI to provide the OS a fake S5 power state? If not, a PV-on-HVM driver could set pm_power_off and use a hypercall, but that means HVM domains would need a Xen driver for some pretty basic functionality. Maybe all vcpus in cpu_halt() should only be cause for a domain shutdown for VTI domains? Hmm. Some OSes on VTI may use cpu_halt() on all vcpu. So I add printk like call PAL_HALT on all cpu, and call domain_shutdown() for VTI domain. Is this OK? Best Regards, Akio Takebe On Wed, 2007-01-24 at 11:14 +0100, [EMAIL PROTECTED] wrote: Selon Isaku Yamahata [EMAIL PROTECTED]: On Wed, Jan 24, 2007 at 11:43:37AM +0900, Akio Takebe wrote: [...] According to SDM vol2 11.9, PAL_HALT places cpu in low power state. Correct. So the current behaviour that xen/ia64 shutdown unconditionally is wrong. Yes, but that's the code in linux/ia64. Why linux/ia64 doesn't call the shutdown EFI runtime service ? I don't know. Maybe Alex knows the answer. I think we need to be sure we're getting the correct expected user behavior for domains. A user expects the following on real hardware: * halt: Machine is stopped, not shutdown, not rebooted. Linux/ia64 uses PAL_HALT for this. * restart/reboot: Machine is reset. Linux/ia64 uses efi.reset_system for this. * poweroff: Machine is turned off. Linux/ia64 uses ACPI S5 power state if pm_power_off is set, otherwise behaves as if halted. So, for PV domains, cpu_halt() should just take the vcpu offline. I don't think there's any reason to special case the last vcpu going offline and shutdown the domain. That's not what real hardware does. Machine restart/reboot should (and does) happen transparently when Xen catches the EFI call. To support poweroff, I think we should set pm_power_off to a Xen specific hypervisor shutdown routine. The abstraction is already in place to do this. Do VTI domains implement enough ACPI to provide the OS a fake S5 power state? If not, a PV-on-HVM driver could set pm_power_off and use a hypercall, but that means HVM domains would need a Xen driver for some pretty basic functionality. Maybe all vcpus in cpu_halt() should only be cause for a domain shutdown for VTI domains? CPU hot-unplug routine also calls cpu_halt(). In that case, only the targeted cpu should be halted. We don't want domain shutdown. If the last vcpu calls PAL_HALT, the domain can be safely shut down. It's safe, but I don't agree that it should. Thanks, Alex ___ 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: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)
Hi, Alex and all Machine restart/reboot should (and does) happen transparently when Xen catches the EFI call. To support poweroff, I think we should set pm_power_off to a Xen specific hypervisor shutdown routine. The abstraction is already in place to do this. OK, I'll try it. pm_power_off is not called from machine_halt(). So if we use halt command to shutdown domain, we cannot halt system... But is this ia64 achtecture specific? I think notifier_chain of ia64die_chain is the best choice. Which is good patch? Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe pm_power_off_version.patch Description: Binary data notifier_call_version.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)
Hi, Anthony In VTI side, ACPI is emulated by ACPI module of Qemu. I think it supports S5. Good news. But I look like Qemu don't trap acpi_power_off called by linux on VTI. I'll investigate it. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)
Hi, Anthony Hi, Anthony In VTI side, ACPI is emulated by ACPI module of Qemu. I think it supports S5. Good news. But I look like Qemu don't trap acpi_power_off called by linux on VTI. I'll investigate it. I'm sorry, the GFW was very old. If I update the latest GFW, I can shutdown domVTi with my patch. As you said, Linux on domVTi call acpi_power_off(), then Qemu-dm emulate ACPI S5 state. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch][RFC] buildconfigs of supporting SPARSEMEM
Hi, This patch is for updating buildconfig. This patch fix the following issue which dom0 reserves waste memory. See the following link. http://lists.xensource.com/archives/html/xen-ia64-devel/2007-01/msg00113.html In the case of linux side, it seems SPARSEMEM is used with NUMA. Actually in linux-2.6.18, NUMA depends on !FLATMEM. == config NUMA bool NUMA support depends on !IA64_HP_SIM !FLATMEM default y if IA64_SGI_SN2 help Say Y to compile the kernel to support NUMA (Non-Uniform Memory Access). This option is for configuring high-end multiprocessor server systems. If in doubt, say N. == So I update buildconfig with SPARSEMEM and NUMA. I tested dom0 boot. This is no problem. I cannot test domU boot, because currently xen-ia64 tree cannot boot domU without my patch. But I think domU boot is no problem if current tree is fixed. Our PRIMEQUEST having small memory cannot boot without this patch. Please test other IPFs. If you have any comments, please. F.Y.I. The following warnig is occurred at compile time with my patch, but this warning is no problem. In file included from /home/takebe/xen-ia64-unstable.hg.070130/linux-2.6.18-xen/include/linux/gfp.h:4, from /home/takebe/xen-ia64-unstable.hg.070130/linux-2.6.18-xen/include/linux/slab.h:14, from /home/takebe/xen-ia64-unstable.hg.070130/linux-2.6.18-xen/include/linux/percpu.h:4, from /home/takebe/xen-ia64-unstable.hg.070130/linux-2.6.18-xen/include/linux/rcupdate.h:41, from /home/takebe/xen-ia64-unstable.hg.070130/linux-2.6.18-xen/include/linux/dcache.h:10, from /home/takebe/xen-ia64-unstable.hg.070130/linux-2.6.18-xen/include/linux/fs.h:229, from /home/takebe/xen-ia64-unstable.hg.070130/linux-2.6.18-xen/drivers/md/dm.h:13, from /home/takebe/xen-ia64-unstable.hg.070130/linux-2.6.18-xen/drivers/md/dm-path-selector.c:12: /home/takebe/xen-ia64-unstable.hg.070130/linux-2.6.18-xen/include/linux/mmzone.h: At top level: /home/takebe/xen-ia64-unstable.hg.070130/linux-2.6.18-xen/include/linux/mmzone.h:604: warning: static declaration of 'pfn_valid' follows non-static declaration include2/asm/maddr.h:72: warning: 'pfn_valid' declared inline after being called include2/asm/maddr.h:72: warning: previous implicit declaration of 'pfn_valid' was here Signed-off-by: Akio Takebe [EMAIL PROTECTED] --- diff -r d0b2022e2403 buildconfigs/linux-defconfig_xen_ia64 --- a/buildconfigs/linux-defconfig_xen_ia64 Mon Jan 29 11:17:15 2007 -0700 +++ b/buildconfigs/linux-defconfig_xen_ia64 Tue Jan 30 18:48:48 2007 +0900 @@ -1,8 +1,9 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.18-xen -# Mon Jan 29 10:01:13 2007 -# +# Tue Jan 30 18:04:41 2007 +# +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options @@ -129,19 +130,26 @@ CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # CONFIG_PERMIT_BSP_REMOVE is not set # CONFIG_PREEMPT is not set CONFIG_SELECT_MEMORY_MODEL=y -CONFIG_FLATMEM_MANUAL=y +# CONFIG_FLATMEM_MANUAL is not set # CONFIG_DISCONTIGMEM_MANUAL is not set -# CONFIG_SPARSEMEM_MANUAL is not set -CONFIG_FLATMEM=y -CONFIG_FLAT_NODE_MEM_MAP=y +CONFIG_SPARSEMEM_MANUAL=y +CONFIG_SPARSEMEM=y +CONFIG_NEED_MULTIPLE_NODES=y +CONFIG_HAVE_MEMORY_PRESENT=y # CONFIG_SPARSEMEM_STATIC is not set +CONFIG_SPARSEMEM_EXTREME=y +# CONFIG_MEMORY_HOTPLUG is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_MIGRATION=y CONFIG_RESOURCES_64BIT=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y -# CONFIG_VIRTUAL_MEM_MAP is not set +CONFIG_NUMA=y +CONFIG_NODES_SHIFT=10 +CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y +CONFIG_HAVE_ARCH_NODEDATA_EXTENSION=y # CONFIG_IA32_SUPPORT is not set CONFIG_IA64_MCA_RECOVERY=y CONFIG_PERFMON=y @@ -172,6 +180,7 @@ CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=y +CONFIG_ACPI_NUMA=y CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] new domain builder fix to boot domU onIA64.
Hi, Isaku Great. I was trying to fix this issue. I can boot domU, and also I can boot domU with my SPARSEMEM config. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch][RFC] buildconfigs of supportingSPARSEMEM
Hi, Alex and Isaku
I'm trying to fix the warning caused by setting SPARSEMEM.
In the case of x86 code, the following check is used instead of pfn_valid().
static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
{
unsigned long pfn = mfn_to_pfn(mfn);
if ((pfn end_pfn)
!xen_feature(XENFEAT_auto_translated_physmap)
(phys_to_machine_mapping[pfn] != mfn))
return end_pfn; /* force !pfn_valid() */
return pfn;
}
mfn_to_local_pfn() is called only by in_swiotlb_aperture().
in_swiotlb_aperture() check pfn_valid(),
so I fix by the following way, what do you think?
diff -r ef646312685f linux-2.6-xen-sparse/include/asm-ia64/maddr.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/maddr.h Wed Jan 31 10:59:56
2007 -0700
+++ b/linux-2.6-xen-sparse/include/asm-ia64/maddr.h Fri Feb 02 01:08:01
2007 +0900
@@ -69,8 +69,11 @@ mfn_to_local_pfn(unsigned long mfn)
mfn_to_local_pfn(unsigned long mfn)
{
unsigned long pfn = mfn_to_pfn_for_dma(mfn);
+#ifndef CONFIG_SPARSEMEM
if (!pfn_valid(pfn))
return INVALID_P2M_ENTRY;
+#endif
+/* we should pfn_valid() in caller function if SARSEMEM. */
return pfn;
}
Best Regards,
Akio Takeeb
Hi Akio,
These end with a build error for me, so I think they should be
cleaned up before this goes in the tree. 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] fix compile warning of xenentry.S
Hi, This patch fix the following compile warnig with srlz.d. /linux-2.6.18-xen/arch/ia64/xen/xenentry.S: Assembler messages: /linux-2.6.18-xen/arch/ia64/xen/xenentry.S:130: Warning: Use of 'st4' violates RAW dependency 'DTC' (data) /linux-2.6.18-xen/arch/ia64/xen/xenentry.S:130: Warning: Only the first path encountering the conflict is reported /linux-2.6.18-xen/arch/ia64/xen/xenentry.S:125: Warning: This is the location of the conflicting usage /linux-2.6.18-xen/arch/ia64/xen/xenentry.S:130: Warning: Use of 'st4' violates RAW dependency 'DTR' (data) /linux-2.6.18-xen/arch/ia64/xen/xenentry.S:130: Warning: Only the first path encountering the conflict is reported /linux-2.6.18-xen/arch/ia64/xen/xenentry.S:125: Warning: This is the location of the conflicting usage Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe cleanup_xenentry_S.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][RFC] buildconfigs of supportingSPARSEMEM
Hi, Isaku On Thu, Feb 01, 2007 at 05:04:33PM +0900, Akio Takebe wrote: mfn_to_local_pfn() is called only by in_swiotlb_aperture(). in_swiotlb_aperture() check pfn_valid(), so I fix by the following way, what do you think? It seems caller's responsibility to check by pfn_valid(). So simple return mfn_to_pfn_for_dma(mfn) is ok instead of #ifndef CONFIG_SPARSEMEM. Adding comment is good thing. Thank you for your comments. I'll update it soon. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch0/2] support config SPARSEMEM
Hi, These patches are for supporting domain config of SPARSEMEM. See the following thread. http://lists.xensource.com/archives/html/xen-ia64-devel/2007-01/msg00278.html [1/2] change config SPARSEMEM [2/2] remove pfn_valid for supporting SPARSEMEM Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch1/2] support config SPARSEMEM
Hi, This patch change buildconfig from FLATMEM to SPARSEMEM. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe config_sparsemem.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] [Patch2/2] remove pfn_valid() in mfn_to_local_pfn() for supporting SPARSEMEM
Hi, This patch remove pfn_valid() in mfn_to_local_pfn(). Caller function of mfn_to_local_pfn() should pfn_valid() in itself. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe remove_pfn_valid_for_sparsemem.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] fix pal halt of para domain
Hi, This patch is for the following issue. http://lists.xensource.com/archives/html/xen-ia64-devel/2007-01/msg00163.html I update it for linux-2.6.18. I tested; 1. domU shutdown 2. domU crash then xend generate domU's core. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe domainU_pal_halt.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] fix pal halt of para domain
Hi, Alex Thank you for your comments. machine_halt() isn't supposed to power off the system. The processors should be left spinning and the domain will be halted, but still in place. machine_power_off() should certainly shutdown the domain, but that's where the pm_power_off hook is useful. I concerned that someuser use halt command instead of shutdown -h now. But you are right, I update it. I though we didn't need this since qemu emulates the S5 power off and we can hook into pm_power_off for PV domains. Did we figure out that doesn't work? Thanks, Qemu emulation don't work because I used old GFW. When I used the latest GFW, I could power off by qemu emulation. 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] [Patch0/2] support config SPARSEMEM
Hi, Alex Hmm, I'm sorry. I can boot dom0, domU with my patches on PRIMEQUEST. I'll check this issue. Best Regards, Akio Takebe Dom0 boots with this, but booting a domU w/ the -xen kernel does bad things: Xen p2m: assign p2m table of [0x, 0x0001) Xen p2m: to [0x0001, 0x000103ffc000) (65536 KBytes) XENBUS: Device with no driver: device/console/0 Unable to handle kernel NULL pointer dereference (address ) swapper[0]: Oops 11012296146944 [1] Modules linked in: Pid: 0, CPU 0, comm: swapper psr : 121008026010 ifs : 840b ip : [a001005010a1] Not tainted ip is at __sync_single+0x61/0x1e0 unat: pfs : 838c rsc : 0008 rnat: 021008026010 bsps: a001000dac30 pr : 00019aa5 ldrs: ccv : fpsr: 0009804c0270033f csd : ssd : b0 : a001005013e0 b6 : a0010062e9a0 b7 : f6 : 0 f7 : 0 f8 : 0 f9 : 0 f10 : 0 f11 : 0 r1 : a001010ff400 r2 : 0030 r3 : a00100cc3b98 r8 : e00103a08928 r9 : r10 : r11 : r12 : a00100cc3b80 r13 : a00100cbc000 r14 : a00100cc3ba0 r15 : e000 r16 : a00100cc3ba8 r17 : a0010116f400 r18 : 0c92 r19 : 00649000 r20 : e5378000 r21 : a00100f283e8 r22 : a00100f283b8 r23 : e000 r24 : 059c r25 : 1000 r26 : 3fff r27 : 0008 r28 : r29 : 1412082a6010 r30 : 8006 r31 : Call Trace: [a0010001d0c0] show_stack+0x40/0xa0 sp=a00100cc3730 bsp=a00100cbd498 [a0010001dd20] show_regs+0x840/0x880 sp=a00100cc3900 bsp=a00100cbd440 [a00100041520] die+0x1c0/0x380 sp=a00100cc3900 bsp=a00100cbd3f0 [a00100065e70] ia64_do_page_fault+0x810/0x940 sp=a00100cc3920 bsp=a00100cbd3a0 [a00100068840] xen_leave_kernel+0x0/0x3c0 sp=a00100cc39b0 bsp=a00100cbd3a0 [a001005010a0] __sync_single+0x60/0x1e0 sp=a00100cc3b80 bsp=a00100cbd348 [a001005013e0] unmap_single+0xa0/0x220 sp=a00100cc3b90 bsp=a00100cbd310 [a00100502b10] swiotlb_unmap_single+0x270/0x320 sp=a00100cc3ba0 bsp=a00100cbd2d0 [a0010006b4e0] dma_unmap_single+0xa0/0xc0 sp=a00100cc3ba0 bsp=a00100cbd298 [a0010062ebe0] cciss_softirq_done+0x240/0x5a0 sp=a00100cc3ba0 bsp=a00100cbd248 [a001004ca680] blk_done_softirq+0x240/0x2a0 sp=a00100cc3ba0 bsp=a00100cbd230 [a001000959b0] __do_softirq+0x1b0/0x340 sp=a00100cc3bb0 bsp=a00100cbd1b0 [a00100095c60] do_softirq+0x120/0x240 sp=a00100cc3bb0 bsp=a00100cbd150 [a00100095e00] irq_exit+0x80/0xa0 sp=a00100cc3bb0 bsp=a00100cbd138 [a001006c49b0] evtchn_do_upcall+0x1d0/0x320 sp=a00100cc3bb0 bsp=a00100cbd0a0 [a00100068240] xen_event_callback+0x380/0x3c0 sp=a00100cc3bb0 bsp=a00100cbd0a0 [a001005013e0] unmap_single+0xa0/0x220 sp=a00100cc3bb0 bsp=a00100cbd0a0 0Kernel panic - not syncing: Aiee, killing interrupt handler! (XEN) Domain 0 crashed: rebooting machine in 5 seconds. (XEN) Domain0 halts the machine ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] fix pal halt of para domain
Hi, Alex and all
machine_halt() isn't supposed to power off the system. The
processors should be left spinning and the domain will be halted, but
still in place. machine_power_off() should certainly shutdown the
domain, but that's where the pm_power_off hook is useful.
I concerned that someuser use halt command instead of shutdown -h now.
But you are right, I update it.
I update it with pm_power_off hook.
Note: halt command may be not able to destroy guest.
machine_halt() isn't support power off of the system.
So we need to destroy guest if we want to power off
it completely, when we halt it.
This is the same behavior as a native machine.
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
---
diff -r 0df9dc2f1d03 linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Thu Feb 01 13:54:26
2007
-0700
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Sun Feb 04 07:54:48
2007
+0900
@@ -95,6 +95,12 @@ static struct notifier_block xen_panic_b
static struct notifier_block xen_panic_block = {
xen_panic_event, NULL, 0 /* try to go last */
};
+void xen_pm_power_off(void)
+{
+ printk(%s called\n, __FUNCTION__);
+ local_irq_disable();
+ HYPERVISOR_shutdown(SHUTDOWN_poweroff);
+}
#endif
extern void ia64_setup_printk_clock(void);
@@ -456,6 +462,7 @@ setup_arch (char **cmdline_p)
/* Register a call for panic conditions. */
atomic_notifier_chain_register(panic_notifier_list,
xen_panic_block);
+ pm_power_off = xen_pm_power_off;
}
#endif
diff -r 0df9dc2f1d03 xen/arch/ia64/xen/fw_emul.c
--- a/xen/arch/ia64/xen/fw_emul.c Thu Feb 01 13:54:26 2007 -0700
+++ b/xen/arch/ia64/xen/fw_emul.c Sun Feb 04 07:54:48 2007 +0900
@@ -605,9 +605,11 @@ xen_pal_emulator(unsigned long index, u6
printk (Domain0 halts the machine\n);
console_start_sync();
(*efi.reset_system)(EFI_RESET_SHUTDOWN,0,0,NULL);
- }
- else
- domain_shutdown(current-domain, SHUTDOWN_poweroff);
+ }else{
+ set_bit(_VCPUF_down, current-vcpu_flags);
+ vcpu_sleep_nosync(current);
+ status = PAL_STATUS_SUCCESS;
+ }
break;
case PAL_HALT_LIGHT:
if (VMX_DOMAIN(current)) {
Best Regards,
Akio Takebe
domU_pal_halt_pm_poweroff.patch
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] cleanup warning of xencons_early_setup
Hi, I include xencons.h into setup.c, and this patch fix warning at compile time. Signed-off-by: Akio Takebe [EMAIL PROTECTED] --- diff -r 0df9dc2f1d03 linux-2.6-xen-sparse/arch/ia64/kernel/setup.c --- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Thu Feb 01 13:54:26 2007 -0700 +++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Sun Feb 04 16:01:31 2007 +0900 @@ -63,6 +63,7 @@ #ifdef CONFIG_XEN #include asm/hypervisor.h #include asm/xen/xencomm.h +#include xen/xencons.h #endif #include linux/dma-mapping.h Best Regards, Akio Takebe cleanup_waning_xencons_early_setup.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] problems with smp
Hi, David Okay got some more information this is kinda odd... If you look it does see the two cpu's but later theres a line about Dom0 max_vcpus=1. How did this get set? is this default? could I set this on the commandline to 2? Hmmm, this seems where it's being set... so all I'd have to do is say dom0_max_vcpus=2 on the xen.gz command line part then? === arch/ia64/xen/domain.c === /* dom0_max_vcpus: maximum number of VCPUs to create for dom0. */ static unsigned int dom0_max_vcpus = 1; integer_param(dom0_max_vcpus, dom0_max_vcpus); Yes. If you alloc two vcpus to dom0, you must add dom0_max_vcpus=2 to command line of xen. If you don't add dom0_max_vcpus, xen alloc one vcpu to dom0. This is default as you said the above. e.g. my elilo.conf image=vmlinuz-2.6.18-xen vmm=xen.gz label=xen initrd=initrd-2.6.18-xen.img read-only append=com2=115200,8n1 console=com2,vga dom0_mem=1G dom0_max_vcpus=2 sync_console -- rhgb root=LABEL=/ 3 console=tty0 console=ttyS1,115200,8n1 Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch 0/2] paravirtualize mmap hundler of /proc/bus/pci to use X server
Hi, On our PRIMEQUEST, I could not bootup Gnome (included in RHEL5) with xen/ia64. This issue is caused by difference of file mmaped by Xorg. The latest Xorg (like one inclued in RHEL5) use /proc/bus/pci/x on some machines. (instead of /dev/mem) Isaku make /dev/mem paravirtulized before. These patches make /proc/bus/pci paravirtulize to use Xwindow on dom0. I can boot Xwindow on dom0/PRIMEQUEST. [1/2] import arch/ia64/pci/pci.c [2/2] paravirtualize mmap hundlers Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch 1/2] import arch/ia64/pci/pci.c
import arch/ia64/pci/pci.c from linux-2.6.18 Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe import_arch_ia64_pci_C.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 2/2] paravirtualize mmap hundlers of /proc/bus/pci
paravirtualize mmap hundler of /proc/bus/pci Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe paravirtualize_pci_mmap_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] Remove panic_domain()
Hi, I found the bug of panic_domain(). When we compile xen with crash_debug=y, debugger_trap_immediate() and debugger_trap_fatal() is not nop. So if xen call panic_domain() to crash guest, xen call debugger routine, then hangup system. domain_crash_synchronous() has __FILE__, __LINE__ macros. So I remove panic_domain() and replace it with printk() and domain_crash_synchronous() as x86 do. I tested dom0/domU/domVTi boot/shutdown. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe remove_panic_domain.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] Remove panic_domain()
Hi, Alex
On Fri, 2007-03-23 at 15:00 +0900, Akio Takebe wrote:
Hi,
I found the bug of panic_domain().
When we compile xen with crash_debug=y, debugger_trap_immediate() and
debugger_trap_fatal() is not nop.
So if xen call panic_domain() to crash guest,
xen call debugger routine, then hangup system.
domain_crash_synchronous() has __FILE__, __LINE__ macros.
So I remove panic_domain() and replace it with printk() and
domain_crash_synchronous() as x86 do.
Wouldn't it work just as well to convert panic_domain() to a macro
and remove the debugger_trap_immediate() and debugger_trap_fatal()
calls? The abstraction of panic_domain() is easier to use than
requiring someone to call all the relevant functions manually. Thanks,
Yes, I used also show_registers() if panic_domain has regs arguments.
(e.g. the following part.)
diff -r 2216a45bf058 xen/arch/ia64/vmx/vlsapic.c
--- a/xen/arch/ia64/vmx/vlsapic.c Tue Mar 20 15:19:38 2007 -0600
+++ b/xen/arch/ia64/vmx/vlsapic.c Fri Mar 23 14:41:48 2007 +0900
@@ -480,8 +480,11 @@ int vmx_check_pending_irq(VCPU *vcpu)
mask = irq_masked(vcpu, h_pending, h_inservice);
if ( vpsr.i IRQ_NO_MASKED == mask ) {
isr = vpsr.val IA64_PSR_RI;
-if ( !vpsr.ic )
-panic_domain(regs,Interrupt when IC=0\n);
+if ( !vpsr.ic ){
+printk(Interrupt when IC=0\n);
+show_registers(regs);
+domain_crash_synchronous();
+}
update_vhpi(vcpu, h_pending);
vmx_reflect_interruption(0, isr, 0, 12, regs); // EXT IRQ
} else if (mask == IRQ_MASKED_BY_INSVC) {
I think panic_domain() don't need debugger_trap_immediate()
and debugger_trap_fatal().
So what I really want to do is removing them.
BTW, as you said, panic_domain() is easier to use than
domain_crash_synchronous() macro.
I make new patch.
We can know the caller function by CallTrace (without __FILE__, __LINE__),
so I only remove the debug routines.
Is the attached new patch better?
Best Regards,
Akio Takebe
remove_debugger_function.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] Remove panic_domain()
Hi,
I forgot signed-off-by
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
Best Regards,
Akio Takebe
Hi, Alex
On Fri, 2007-03-23 at 15:00 +0900, Akio Takebe wrote:
Hi,
I found the bug of panic_domain().
When we compile xen with crash_debug=y, debugger_trap_immediate() and
debugger_trap_fatal() is not nop.
So if xen call panic_domain() to crash guest,
xen call debugger routine, then hangup system.
domain_crash_synchronous() has __FILE__, __LINE__ macros.
So I remove panic_domain() and replace it with printk() and
domain_crash_synchronous() as x86 do.
Wouldn't it work just as well to convert panic_domain() to a macro
and remove the debugger_trap_immediate() and debugger_trap_fatal()
calls? The abstraction of panic_domain() is easier to use than
requiring someone to call all the relevant functions manually. Thanks,
Yes, I used also show_registers() if panic_domain has regs arguments.
(e.g. the following part.)
diff -r 2216a45bf058 xen/arch/ia64/vmx/vlsapic.c
--- a/xen/arch/ia64/vmx/vlsapic.c Tue Mar 20 15:19:38 2007 -0600
+++ b/xen/arch/ia64/vmx/vlsapic.c Fri Mar 23 14:41:48 2007 +0900
@@ -480,8 +480,11 @@ int vmx_check_pending_irq(VCPU *vcpu)
mask = irq_masked(vcpu, h_pending, h_inservice);
if ( vpsr.i IRQ_NO_MASKED == mask ) {
isr = vpsr.val IA64_PSR_RI;
-if ( !vpsr.ic )
-panic_domain(regs,Interrupt when IC=0\n);
+if ( !vpsr.ic ){
+printk(Interrupt when IC=0\n);
+show_registers(regs);
+domain_crash_synchronous();
+}
update_vhpi(vcpu, h_pending);
vmx_reflect_interruption(0, isr, 0, 12, regs); // EXT IRQ
} else if (mask == IRQ_MASKED_BY_INSVC) {
I think panic_domain() don't need debugger_trap_immediate()
and debugger_trap_fatal().
So what I really want to do is removing them.
BTW, as you said, panic_domain() is easier to use than
domain_crash_synchronous() macro.
I make new patch.
We can know the caller function by CallTrace (without __FILE__, __LINE__),
so I only remove the debug routines.
Is the attached new patch better?
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] cleanup vcpu *d
Hi, This pach replaces vcpu *d to vcpu *v. I tested dom0/domU/domVTi boot/shutdown. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe cleanup_vcpu_pointer_name.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][RFC] Auto setup serial console on PRIMEQUEST
Hi,
I make a patch to use serial console without setting bootparameter on PQ.
I change the intel_tiger_console_setup(),
but should I add a function for PRIMEQUEST?
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
---
diff -r 56caf0e37e6a xen/arch/ia64/linux-xen/setup.c
--- a/xen/arch/ia64/linux-xen/setup.c Mon Mar 26 10:10:31 2007 -0600
+++ b/xen/arch/ia64/linux-xen/setup.c Thu Apr 05 12:01:40 2007 +0900
@@ -316,7 +316,7 @@ io_port_init (void)
#ifdef XEN
static int __init
-intel_tiger_console_setup(void)
+machine_console_setup(void)
{
extern struct ns16550_defaults ns16550_com1;
efi_system_table_t *systab;
@@ -352,9 +352,19 @@ intel_tiger_console_setup(void)
if (strncmp(hdr-signature, XSDT_SIG, sizeof(XSDT_SIG) - 1))
return -ENODEV;
-
/*
-* Only looking for Intel Tiger systems
+* looking for Fujitsu PRIMEQUEST systems
+*/
+ if (!strncmp(hdr-oem_id, FUJITSPQ, 8)
+ (!strncmp(hdr-oem_table_id, PQ, 2))){
+ ns16550_com1.baud = BAUD_AUTO;
+ ns16550_com1.io_base = 0x3f8;
+ ns16550_com1.irq = 48;
+ return 0;
+ }
+
+ /*
+* looking for Intel Tiger systems
* Tiger 2: SR870BH2
* Tiger 4: SR870BN4
*/
@@ -402,7 +412,7 @@ early_console_setup (char *cmdline)
#endif
#ifdef XEN
- if (!intel_tiger_console_setup())
+ if (!machine_console_setup())
earlycons++;
#endif
return (earlycons) ? 0 : -1;
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch][RFC] Auto setup serial console onPRIMEQUEST
Hi, Alex Thank you for your work. PRIMEQUEST probalbly don't have HCDP table because we see the following boot message. (There is not HCDP=%lx message.) EFI v1.10 by Fujitsu: SALsystab=0x7fded700 ACPI 2.0=0x7fc7c000 SMBIOS=0xf Best Regards, Akio Takebe On Thu, 2007-04-05 at 10:44 +0900, Akio Takebe wrote: Hi, I make a patch to use serial console without setting bootparameter on PQ. I change the intel_tiger_console_setup(), but should I add a function for PRIMEQUEST? Hi Akio, Looks good. I might change machine_console_setup() to acpi_oem_console_setup() (no need for a new patch), but I don't see a need for a separate function. So the PRIMEQUEST system don't implement an HCDP table either? 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 xm dump-core with vti domain
Hi, Isaku Thank you for your work! I'll check it and close bugzilla. Best Regards, Akio Takebe fix xm dump-core with VT-i domain. Share privregs with domain and assign it to pseudo physical address space as para virtualized domain. This patch should resolve bug #976. Akio, could you confirm it and close the bug report? -- yamahata ---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] Problem with xen-3.0.4_1-src.tgz compilation onia64
Hi, Radek
I have never try xen-3.0.4_1_src,
bt if you modify domain.c like the below, you can compile it.
--- xen/arch/ia64/xen/domain.c.orig 2007-04-05 20:26:43.0 +0900
+++ xen/arch/ia64/xen/domain.c 2007-04-05 20:26:58.0 +0900
@@ -867,7 +867,7 @@ int shadow_mode_control(struct domain *d
#endif
// see arch/x86/xxx/domain_build.c
-int elf_sanity_check(Elf_Ehdr *ehdr)
+int elf_sanity_check(const Elf_Ehdr *ehdr)
{
if (!(IS_ELF(*ehdr)))
{
Best Regards,
Akio Takebe
Hi,
Very shortly:
make world
(...)
gcc -O2 -fomit-frame-pointer -DNDEBUG -std=gnu99 -Wall
-Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement
-nostdinc -fno-builtin -fno-common -fno-strict-aliasing -mconstant-gp
-O2 -fomit-frame-pointer -D__KERNEL__ -iwithprefix include
-I/usr/src/xen-3.0.4_1-src/xen/include
-I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64
-I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64/linux
-I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64/linux-xen
-I/usr/src/xen-3.0.4_1-src/xen/include/asm-ia64/linux-null
-I/usr/src/xen-3.0.4_1-src/xen/arch/ia64/linux
-I/usr/src/xen-3.0.4_1-src/xen/arch/ia64/linux-xen -DIA64 -DXEN
-DLINUX_2_6 -ffixed-r13 -mfixed-range=f2-f5,f12-f127 -g
-DCONFIG_XEN_IA64_EXPOSE_P2M -DCONFIG_XEN_IA64_PERVCPU_VHPT
-DCONFIG_XEN_IA64_TLB_TRACK -DCONFIG_XEN_IA64_TLBFLUSH_CLOCK -g
-D__XEN__ -c domain.c -o domain.o
domain.c:871: error: conflicting types for 'elf_sanity_check'
/usr/src/xen-3.0.4_1-src/xen/include/xen/elf.h:529: error: previous
declaration of 'elf_sanity_check' was here
make[6]: *** [domain.o] Error 1
make[6]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen/arch/ia64/xen'
make[5]: *** [xen/built_in.o] Error 2
make[5]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen/arch/ia64'
make[4]: *** [/usr/src/xen-3.0.4_1-src/xen/arch/ia64/built_in.o] Error 2
make[4]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen/arch/ia64'
make[3]: *** [/usr/src/xen-3.0.4_1-src/xen/xen] Error 2
make[3]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/usr/src/xen-3.0.4_1-src/xen'
make[1]: *** [install-xen] Error 2
make[1]: Leaving directory `/usr/src/xen-3.0.4_1-src'
make: *** [world] Error 2
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Problem with xen-3.0.4_1-src.tgz compilation onia64
Hi, Radek Hi! Indeed it helped. Shame that it is not in the official source :( You said that you didn't try to use 3.0.4. Which would you prefer instead then? Yeah. That is a actual question. Then the /usr/src/xen-3.0.4_1-src/linux-2.6.16.33-xen# make CHK include/linux/version.h CHK include/linux/compile.h CHK usr/initramfs_list CC arch/ia64/xen/../../i386/kernel/pci-dma-xen.o arch/ia64/xen/../../i386/kernel/pci-dma-xen.c:18:25: error: asm/swiotlb.h: No such file or directory make[1]: *** [arch/ia64/xen/../../i386/kernel/pci-dma-xen.o] Error 1 make: *** [arch/ia64/xen] Error 2 In fact there is no such file. Looks like some patch is not included during the build process or ... ? Hm. You apply the following patch. And if you do make kdelete, make kernels, you must compile it. http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/8af3df2f4b01 When you install it, you see the following documents. xen/arch/ia64/tools/README.xenia64 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] Problem with xen-3.0.4_1-src.tgz compilation onia64
Hi, Radek
I always use xen-ia64-unstable.hg because I develop it.
Current xen-ia64 is very stable.
And you may use RHEL5.
Best Regards,
Akio Takebe
2007/4/5, Akio Takebe [EMAIL PROTECTED]:
Hi, Radek
I have never try xen-3.0.4_1_src,
bt if you modify domain.c like the below, you can compile it.
--- xen/arch/ia64/xen/domain.c.orig 2007-04-05 20:26:43.0 +0900
+++ xen/arch/ia64/xen/domain.c 2007-04-05 20:26:58.0 +0900
@@ -867,7 +867,7 @@ int shadow_mode_control(struct domain *d
#endif
// see arch/x86/xxx/domain_build.c
-int elf_sanity_check(Elf_Ehdr *ehdr)
+int elf_sanity_check(const Elf_Ehdr *ehdr)
{
if (!(IS_ELF(*ehdr)))
{
Hi!
Indeed it helped.
Shame that it is not in the official source :(
You said that you didn't try to use 3.0.4.
Which would you prefer instead then?
Radek
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] fix xm dump-core with vti domain
Hi, Isaku By using this patch, we can get dump-core of HVM domain well. Thanks again! I close bugzilla. Best Regards, Akio Takebe Hi, Isaku Thank you for your work! I'll check it and close bugzilla. Best Regards, Akio Takebe fix xm dump-core with VT-i domain. Share privregs with domain and assign it to pseudo physical address space as para virtualized domain. This patch should resolve bug #976. Akio, could you confirm it and close the bug report? -- yamahata ---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] [Patch] fix serial console setting of PRIMEQUEST
Hi, Alex I mistake the previous patch to use serial console. I thought ns16550_com1.irq was irq number, but this is gsi number. So I fix it and use ns16550_com1_gsi to call iosapic_register_intr(). When I made the previous patch, I used sync_console option, so I don't notice the issue. We can use serial console without sync_console otpion on PRIMEQUEST. Please apply this patch. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe fix_pq_serial_cofig.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] $B:G?7$N(Bkernel-xen$B$N(Bsrc.rpm
桑村殿？、統合各位？ 竹部です。 RHEL5GA＋先行修正の最新のkernel, xenのsrc.rpmがほしいのですが、 何処からダウンロードしたら良いでしょうか？ 以上 ◇◇◇◇◇◇ 富士通株式会社 プラットフォーム技術開発本部 仮想システム開発統括部 竹部 晶雄(Takebe Akio) ★B4Fに移りました 外線:055-924-7241(内線:7551-5366) Fax:055-924-6196 mailto:[EMAIL PROTECTED] ◇◇◇◇◇◇ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] support debug_keys on ia64
Hi, This patch supoprt xm debugkeys. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regsrds, Akio Takebe support_debug_keys.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] cleanup warning of UC|WB attribute page
Hi, Isaku Thank you for your comments. I updated my patch. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe cleanup_warning_efi_uc2wb.v2.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] cleanup warning of UC|WB attributepage
Hi, Alex and all Why does efi_ucwb() only check certain types of ranges for having both UC and WB attributes. Seems like the types might be implementation specific. I'm also a little concerned about scanning the EFI memory map, but I guess this is expected to be a rare event. Is there an approach we could take to prevent these cases from happening (for a well behaved guest) rather than catching them at the end? Thanks, Exactly, I'll update the patch as efi_ucwb() don't check EFI Mermoy Type if we choice this approch. And as you said, this case is rare. So this scanning should not affect performance. BTW, I also thought another approch to prevent these case. Because these memory area is accessed as both UC and WB, we need to use new flag. (For example _PAGE_MA_UCE, I'm not sure we can use this flag for UC|WB. or should we make new flag?) In consideration of stability, I didn't make new flag. (Because I must check many part of memory access.) Which approch do you prefer? or another suggestion? Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] cleanup warning of UC|WB attributepage
I remade the patch as efi_ucwb() don't check EFI Mermoy Type. If we choice this approch, please apply it. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe cleanup_warning_efi_uc2wb.v3.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] cleanup warning of UC|WB attributepage
Hi, Alex On Tue, 2007-05-08 at 09:58 +0900, Akio Takebe wrote: BTW, I also thought another approch to prevent these case. Because these memory area is accessed as both UC and WB, we need to use new flag. (For example _PAGE_MA_UCE, I'm not sure we can use this flag for UC|WB. or should we make new flag?) In consideration of stability, I didn't make new flag. (Because I must check many part of memory access.) Which approch do you prefer? or another suggestion? That does sound rather involved. Unless others think the UCE page is a better way to go, perhaps we should use something like the approach you're suggesting. Newer upstream efi.c has a efi_mem_attribute() function that will give you the attributes for a given range of memory. Rather than implementing yet another EFI memmap walking routine, what do you think about updating efi.c to a newer upstream version and making use of this function? Thanks, Thank you for your comments. I'll check whether It is possible easy to port new efi.c to xen. 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] VTD is coming
Hi, Anthony I have a question. Do we need to set not only tables included dma page but also all page table to VTd? If yes, do we need to diable dma even when we chage any page table not related in dma-remapping? 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] VTD is coming
Hi, Anthony Thank you for your explanation. I have a question. Do we need to set not only tables included dma page but also all page table to VTd? We don't know which pages guest OS will use as dma page, So we let vtd page table translate all physical address belonging to guest. If yes, do we need to diable dma even when we chage any page table not related in dma-remapping? we needn't and can't. Vtd page table is maintained by xen. When xen changes vtd page table, the changed entries should not be used by DMA operation. What xen needs to do is to flush corresponding IO- TLBs. Thanks, I understand. Another question, xen don't know dma pages used by guest, how about can xen protect the dma pages? (Sorry, I'll read VTd spec much more.) Do you find the scenarios where race conditions exist? No, I was warried about performance at the time of changing page table. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] Speculative Load/Store to IO memory
Hi, We met a panic_domain(NULL, Undefined IPI-LHF read!\n), when we run test on Windows guest. When the issue was occurred, the guest did ld4.s r49=[r27]. Reading IO memory by using lds is wrong. But if the instruction is speculative, Xen should set psr.ed then return to guest. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Kouya Shimura [EMAIL PROTECTED] Best Regards, Akio Takebe fix_speclative_io_memory.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] Speculative Load/Store to IO memory
Hi, Anthony Thank you for yor comments. From the patch, guest executes ld.s on physical mode. Is this a cacheable address(region 0) or un-cacheable address(region 4)? No, this guest work on virtual mode. My patch is for virtual mode. This address is 0xa000fee00018. When we found the isssue, arguments of mmio_access() are (f798, fee00018, f7987d80, 4, 4, 1), so I think it is un-cachable. If it is a un-cacheable address, According to spec, the behavior of ld.s on un-cacheable page is undefined. We can set psr.ed directly. Is cheking ma=4 better? If it is a cacheable address and it is IO address. I don't know the real behavior on native machine. So we need to get the real behavior first, then decide how to emulate it. I'm asking some exports, hope I can get the answer. Thanks. This issue is difficult to reproduce, because we don't know step to reproduce. 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] Serial woes with kexec on an HP RX2620
Hi, Horms After kexec, what kernel do you use? Xen or linux kernel? I think you don't call iosapic_register_intr(), arguments of iosapic_register_intr() are wrong. Can you check that efi.hcdp is passed to second kernel properly? FYI In the case of xen, HP machine call the following functions. efi_setup_pcdp_console() setup_serial_console() setup_pcdp_irq() pcdp_hp_irq_fixup() And iosapic_register_intr() is called in start_kernel(). Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [RFC] Warning at move_native_irq()
Hi, I met the following WARN_ON(1) when I booted smp domU of RHEL5. This message is occurred by setting desc-move_irq=1. I investigated this issue, I found move_irq is 1 when irqbalance is on. Probably irqbalance call set_pending_irq(). How should we solve the issue? Any idea? BUG: warning at /home/takebe/xen-3.1-testing.hg/linux-2.6.18-xen/kernel/irq/ migration.c:27/move_native_irq() Call Trace: [a0010001cd40] show_stack+0x40/0xa0 sp=a00100c539e0 bsp=a00100c4d1e0 [a0010001cdd0] dump_stack+0x30/0x60 sp=a00100c53bb0 bsp=a00100c4d1c8 [a001000de6d0] move_native_irq+0xd0/0x360 sp=a00100c53bb0 bsp=a00100c4d190 [a001006ac700] ack_dynirq+0x40/0x100 sp=a00100c53bb0 bsp=a00100c4d170 [a001000d95a0] __do_IRQ+0x100/0x420 sp=a00100c53bb0 bsp=a00100c4d128 [a001006ad2c0] evtchn_do_upcall+0x1c0/0x320 sp=a00100c53bb0 bsp=a00100c4d090 [a00100067c80] xen_event_callback+0x380/0x3c0 sp=a00100c53bb0 bsp=a00100c4d090 Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch][0/2] cleanup warning of UC|WB attribute page (take3)
Hi, I posted the previous patch to the following thread. http://lists.xensource.com/archives/html/xen-ia64-devel/2007-05/msg00038.html [1/2] update efi.c and efi.h to linux-2.6.21 [2/2] cleanup warning Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch][1/2] update efi.c and efi.h to linux-2.6.21
Hi, I update efi.c and efi.h. I imported them from linux-2.6.21, and modified them for XEN. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards Akio Takebe efi_update.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][2/2] cleanup warning of UC|WB attributepage
Hi, This patch cleanup the following warning. (XEN) mm.c:497:d0 Warning: UC to WB for mpaddr= Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards Akio Takebe cleanup_warning_efi_ucwb.v3.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] Re: [Xen-devel][PATCH]NVRAM support for IA64
Hi, Wing CC: Keir and Ewan Attachment is a patch implementing NVRAM for IA64. The patch is to add patch through libxc to remove the file access dependency from Qemu. The patch doesn't touch much of the common code, just add a hook in Xend and a HVM param in XEN. Hope your comments on it. Nvram is important to IA64, we got many requirements for it.Thx:-) Wing, this patch is great improvement. Without this patch, we cannot boot windows 2008, and also cannot boot windows 2003 automatically on ia64. I have a few commens. PERROR doesn't print messages because libxc doesn't have terminal. So it is better to pass Error codes (e.g. ENOMNT, EPERM..) to xend so xend can catch exceptions and, as a result, it puts error messages in xend.log. How do you like this? Keir and Ewan, do you have any other comments? Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
