RE: [Xen-ia64-devel] ia64 builds broken in xen-unstable mainline
Isaku, You may need to create a patch to workaround the issue first since our PRC team is on the national holiday for the week. Thanks, -Fred Isaku Yamahata wrote: Sorry for that. This should be fixed by Yu's patches. I've been waiting for Yu to respin the patches. Yu? If it would take a while, I could create a band aid patch to define those symbols. thanks, On Tue, Sep 30, 2008 at 12:08:04PM +0100, Ian Jackson wrote: Currently the automatic patch forwarding machinery which sits between commits to xen-unstable mainline and the public non-staging tree isn't feeding anything through because the ia64 build is broken: .../xen/drivers/built_in.o: In function `set_px_pminfo': .../xen/drivers/cpufreq/cpufreq.c:226: undefined reference to `get_cpu_id' .../xen/drivers/cpufreq/cpufreq.c:268: undefined reference to `xenpf_copy_px_states' .../xen/drivers/cpufreq/cpufreq.c:303: undefined reference to `cpufreq_cpu_init' This looks like it was introduce in one of these changes: changeset: 18552:19b0a4f91712 summary: x86 and ia64: move cpufreq notify code to commone place changeset: 18551:d1d9915041de summary: X86 and IA64: Update cpufreq statistic logic for supporting both x86 changeset: 18550:08374be21318 summary: X86 and IA64: Rebase cpufreq logic for supporting both x86 and ia64 Perhaps an ia64 part is missing ? It would be nice to get this fixed ... Thanks, Ian. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] Xen/ia64 maintainership transition
Alex, Your great effort has lead IA64 Xen achieved great product quality and performance. Thanks, Cheers to Isaku! -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: Tuesday, May 06, 2008 7:47 PM To: xen-ia64-devel Cc: Isaku Yamahata; xen-devel; Keir Fraser Subject: [Xen-devel] Xen/ia64 maintainership transition Hi all, The Xen/ia64 project has come a long way in the past few years, and it's with some satisfaction and excitement that I announce the transition of the maintainership. Isaku Yamahata, who is easily the biggest contributor to the project and in many ways the technical expert, has graciously agreed to take over this role. I've been working with Isaku on infrastructure and testing setup, and will continue to help as needed until Isaku is comfortable. I intend to stay involved with the project, but after over two years as the maintainer, I'm ready for a change. Congratulations and best of luck Isaku, thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ 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
[Xen-ia64-devel] Paravirt_ops directions and next steps
Following http://lists.xensource.com/archives/html/xen-ia64-devel/2008-01/msg00230 .html discussion on pv_ops, several of us from companies had a phone meeting on 3/13 on how to best approach pv_ops for Xen/IA64 in time to get code upstream kernel. The mail here is to catch common agreement and approach. For the meeting attendees, please correct me if the mail doesn't catch agreements correctly. Group agrees to take pv_ops proposal described in http://lists.xensource.com/archives/html/xen-ia64-devel/2008-03/msg00107 .html is the goal and best way to achieve a single image to run on both native and virtual machines (VM), though group also recognizes the architectural differences between IA64 and IA32 may not easy for IA64 to fully adapt pv_ops from IA32 and push code upstream kernel in reasonable time. Isaku has been working a forward port of DomU to 2.6.25 kernel in git://gitorious.org/linux-2-6-xen-ia64-pv-ops/mainline.git with some pv_ops approaches, though not necessarily the same with existing IA32 pv_ops. Group believes it best start with Isaku's code as base for clean up and split into small patches in pushing upstream kernel, and gradually adapting IA32 pv_ops; though intermediate code may have if PARAVIRT_XEN, the goal is to have single image for both native and VM. Group agrees to take dual-IVT table approach due to IA64 native is very performance sensitive in IVT handling, and will gradually be merged in to one when the performance can be achieved to match with native. Welcome community in contributing efforts, -Fred ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Open GFW for RHEL release.
Tristan Gingold wrote: On Tue, Feb 19, 2008 at 09:44:36AM -0800, Yang, Fred wrote: Tristan, To get Open GFW into RHEL official release, Open GFW needs to do 1. An official release - a proper versioned formal release of GFW. A self-contained tar.gz for all the sources for RHEL to pull Please start doing the release. It will be definitely great to always to have a pre-built image for each release. 2. Simplified way to build Open GFW - RHEL is using rpm mechanism; EDK by itself is quite different rpm and not easy to be folded into standard build process. Any way to simplify this? Tianocore is changing its build mechanism. The new one is mostly python based and therefore should be much much easier to use. However it is not yet fully released and we still have to synch our GFW with the head. Python will be good! But we need to wait on this one! (:- Thanks, -Fred ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] paravirt_ops and its alternatives
Alex Williamson wrote: On Mon, 2008-02-04 at 09:53 +0800, Dong, Eddie wrote: Yang, Fred wrote: Dong, Eddie wrote: Re-post it to warmup discussion in case people can't read PPT format, IVT is very performance sensitive for the native Linux, how about dual IVT tables alternative for CPU virtualization? It would need maintainance effort but it would be much cleaner forIA64 situation. -Fred Dual IVT table could be a night mare for Tony, I guess. But yes we need to have more active discussion to kick it off. Yes, two separate IVTs with 95+% of the code being the same would not be ideal. I think we should aim for a single ivt.S that gets compiled a couple times with different options, once for native and again for each virtualization option. It looks like more than half of the changes in xenivt.S could be easily converted to macros that could be switched by compile options. Perhaps a pattern will emerge for the rest. If it is not necessarily to stick with a single image and runtime to determine code path, multi-compile paths to generate different PV or native image then macros can possibly work.. -Fred ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] paravirt_ops and its alternatives
Dong, Eddie wrote: Re-post it to warmup discussion in case people can't read PPT format, IVT is very performance sensitive for the native Linux, how about dual IVT tables alternative for CPU virtualization? It would need maintainance effort but it would be much cleaner forIA64 situation. -Fred ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Open Guest Firmware/IPF test report
Community, Please also validate the OpenGFW accordingly. We would like to have this OpenGFW as IA64/Xen standard GFW and push to OSV ASAP. Thanks, -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:xen-ia64-devel- [EMAIL PROTECTED] On Behalf Of Mu, Qin Sent: Thursday, December 13, 2007 5:25 PM To: xen-ia64-devel Subject: [Xen-ia64-devel] Open Guest Firmware/IPF test report Hi, A light validation cycle for IPF open guest firmware of Cset# 38 was completed. Please see the attached validation report for detailed information. Test Results Summary = Summary: 1. Guest HVM of both linux and windows OS type can be launched with or without nvram file. No abnormity detection occurred during guest HVM booting phase based on open guest firmware. 2. Each system component under observation can be correctly recognized and setup by OS with expected information and the basic functionalities are achieved. 3. Screen resolution and color quality setting can efficiently take effect in guest HVMs. The actual screen quality can be achieved consistently as expected. Issues: -- 1. Standard VGA can't be supported in either linux or windows guest HVM when stdvga option was switched on in configuration file. a) Linux guest HVM X11 desktop can't launch and the following information was given by lspci command: VGA compatible controller; Technical Corp. Unknown device (prog-if 00 [VGA]) Flags: fast devsel Memory at c000 (32bit, prefetchable) [size=8M] b) Windows guest HVM VGA device was recognized as Standard VGA Graphic Adapter although it failed to start. 2. Even if configured with USB mouse in guest HVM, mouse's behavior is too far from users' expectation to tolerate, particularly to window guys. Thanks! Qin Mu ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen summit
Subject: Re: [Xen-ia64-devel] Xen summit Hi, Aron As I think you know, I volunteered to do the xen/ia64 status update since Alex won't be at the summit next week. I'm planning to talk about the ia64 work that's been accomplished since April, plus talk about the roadmap that has been discussed recently on this list. Who's coming? In the past we've held an informal BOF to talk about issues, progress, and just get to know each other better. Would you like to do that again? Yoshi, Matsumoto, Ezaki, Kama and Akio will be there. I also hope the BOF. I will be there too! -Fred ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] eepro100 HVM NIC
Alex, Xing was also looking into eepro100 effort before; he should be able to share info after PRC holiday Thanks, -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:xen-ia64-devel- [EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: Thursday, October 04, 2007 8:25 PM To: xen-ia64-devel Subject: [Xen-ia64-devel] eepro100 HVM NIC I spent some time porting the eepro100 device device model from qemu into Xen. It seems to work ok for Linux guests, but I can't get it working for Windows. The qemu driver supports three models of the card: i82551, i82557b, and i82559er. The i82557b is definitely recognized by the i8255x driver that ships with Windows server 2003. The other two just show up as unknown devices in the device manager. The most obvious thing keeping it from working seems to be that Windows remaps the PCI BARs to invalid addresses (the reason I was investigating the memmap, but that didn't help). I don't understand why it's doing this, but I'll post the port of the eepro100 driver here to save anyone who wants to play with it the trouble. FWIW, I also tried the Windows IPF driver available from Intel's website, but it didn't recognize any of the models as a PRO series NIC and refused to install. 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] support more than 8vcpu for windowssever 2003 SP1
Alex, Windows Server SP1 will show running 16cpus on native Tiger4 systems. With this patch the Guest Windows can get to the same behavior rather than only 8 vcpus without patch. For Datacenter version, it is shows the similar behavior. Thanks, -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:xen-ia64-devel- [EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: Friday, May 18, 2007 6:00 AM To: Zhang, Xing Z Cc: xen-ia64-devel Subject: Re: [Xen-ia64-devel][PATCH] support more than 8vcpu for windowssever 2003 SP1 On Fri, 2007-05-18 at 12:30 +0800, Zhang, Xing Z wrote: Add two PAL calls and one SAL call. windows sever 2003 SP1 or SP2 can boot more than 8 cpus on native, but only 8 vcpus in VTI. This patch make VTI has same behavior with native. I thought we solved this in the GFW with adding hotplug support. I'm really not in favor of adding complications to vCPUs by making them appear as dual core processors. Does this allow Enterprise or Data Center to go to more than 8 vCPUs? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH] optimization for windows
-Original Message- From: [EMAIL PROTECTED] [mailto:xen-ia64-devel- [EMAIL PROTECTED] On Behalf Of Jürgen Groß Xu, Anthony wrote: This is optimization for windows 2003. Windows use region 4 and region 5 for identity mapping. I see ~3% improvement when running specjbb2005 on guest windows after applying this patch. Did I understand this correct? If Region 7 preferred page size is 8kB, Region 4 and 5 will be identity mapping, regardless of DomU type? Please understand DomU and HVM are running independently, there is no interfere in between. For all the virtualization, there will be some assumption there, no one size fits all. The specific example is PV Linux ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Fully virtualized doamin passed 48hr stress tests
FYI, Fully virtualized Domain, run on Xen/VTi, has successfully passed continuous 48 hours stress tests. Environment: Dual-Core Intel(r) Itanium(r) 2 processor 9000 series Tiger4 system 4 sockets with MT disabled Xen Cset# 11460 Guest OS: RHEL4U2 Xen environment: Xen0: Dual Processors DomainVTi: 2 SMP domains, each with 3 vcpus Stress Tests: 1. Helltest: 16 hours 2. Crashme: 16 hours 3. In-house compatability validation suites: 16 hours The system has passed total 48 hours stress tests -Fred ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result
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
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 gnome-settings-(3187): unaligned access to 0x6eb9f3ec, ip=0x21cb ada0 gnome-settings-(3187): unaligned access to 0x6eb9f3ec, ip=0x21cb ada0 (XEN) ### domain f7c68080: rid=8-c mp_rid=2000 (XEN) arch_domain_create: domain=f7c68080 (XEN) DomainU EFI build up: ACPI 2.0=0x1000 (XEN) dom mem: type=13, attr=0x8008, range=[0x-0x000 01000) (4KB) (XEN) dom mem: type=10, attr=0x8008, range=[0x1000-0x000 02000) (4KB) (XEN) dom mem: type= 6, attr=0x8008, range=[0x2000-0x000 03000) (4KB) (XEN) dom mem: type= 7, attr=0x0008, range=[0x3000-0x000 00fff4000) (255MB) (XEN) dom mem: type=12, attr=0x0001, range=[0x0c00-0x000 01000) (64MB) (XEN) vcpu_get_lrr0: Unmasked interrupts unsupported (XEN) vcpu_get_lrr1: Unmasked interrupts unsupported (XEN) Linux version 2.6.17-1.2630.fc6xen ([EMAIL PROTECTED]) ( gcc version 4.1.1 20060828 (Red Hat 4.1.1-20)) #1 SMP Wed Sep 6 16:30:45 EDT 200 6 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, 0xe4c187a3) rsvd_region[3]: [0xefff4000, 0xefff8000) rsvd_region[4]: [0x, 0x) 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 bootmem alloc of 67141632 bytes failed! Kernel panic - not syncing: Out of memory ### domain f4fb0080: rid=8-c mp_rid=2000 (XEN) arch_domain_create: domain=f4fb0080 (XEN) DomainU EFI build up: ACPI 2.0=0x1000 (XEN) dom mem: type=13, attr=0x8008, range=[0x-0x000 01000) (4KB) (XEN) dom mem: type=10, attr=0x8008, range=[0x1000-0x000 02000) (4KB) (XEN) dom mem: type= 6, attr=0x8008, range=[0x2000-0x000 03000) (4KB) (XEN) dom mem: type= 7, attr=0x0008, range=[0x3000-0x000 00fff4000) (255MB) (XEN) dom mem: type=12, attr=0x0001, range=[0x0c00-0x000 01000) (64MB) (XEN) vcpu_get_lrr0: Unmasked interrupts unsupported (XEN) vcpu_get_lrr1: Unmasked interrupts unsupported (XEN) Linux version 2.6.17-1.2630.fc6xen ([EMAIL PROTECTED]) ( gcc version 4.1.1 20060828 (Red Hat 4.1.1-20)) #1 SMP Wed Sep 6 16:30:45 EDT 200 6 EFI v1.00 by Xen/ia64: SALsystab=0x2178 ACPI 2.0=0x1000 rsvd_region[0]: [0xe0002228, 0xe00022f0) rsvd_region[1
RE: [Xen-ia64-devel] xen-ia64-unstable.hg status
Alex, VTi network issue has be root caused to GFW conflict with latest QEMU addsing a fake PCI device (xen_platform) for VBD/VNIF which is using IRQ 10 same as NIC. A new GFW will be sent out separately. We have a patch for VTi Reboot issue but are seeing kernel panic, so we are continue to debug the new patch Thanks, -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:xen-ia64-devel- [EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: Wednesday, August 23, 2006 3:44 PM To: xen-ia64-devel Subject: [Xen-ia64-devel] xen-ia64-unstable.hg status I merged us up with xen-unstable.hg. For the most part things still work well, but there seem to be a few regressions (networking on VTi domains is broken again and rebooting domains is less reliable). I'd like to request a pull within the next day or so, therefore please take a moment to test as this may be our last pull before 3.0.3. I'd like to include all of the currently outstanding patches, especially the pal_halt_light emulation patch, so let's try to get that one figured out so that everyone is happy with it. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Pulling Xen-unstable
Alex, Will it be possible to pull Xen-unstable againg? We have been working to get Xen-unstable to boot with latest QEMU 0.8.1 and seeing there are a lot of Csets different between Xen-unstable xen-ia64_unstable now. To further sure the patches won't be missed or collide between 2 trees, we would like your help to pull Xen-unstable so we can work on the latest IA64 code. Xiantao has submitted 2 patches to xen-unstable, so the new merged QEMU should be able to build for IA64 Thanks, -Fred ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] fix qemu on ia64 - work in progress
Yes, likely we need to tackle from xen-unstable. IA32 team is digging into it now! -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:xen-ia64-devel- [EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: Thursday, July 13, 2006 4:10 PM To: xen-ia64-devel Subject: [Xen-ia64-devel] fix qemu on ia64 - work in progress This doesn't work yet, but it makes tools/ioemu build on ia64 in xen-unstable.hg and reintroduces the more obvious missing components. Starting a domVTI fails with 'Cannot allocate memory' with this patch. Hopefully it can jump start anyone else that wants to start digging into how to fix qemu on xen-unstable. Thanks, Alex ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] VTi domain panic - use of invalid rid 40000
Alex, This should have been fixed in the latest (06/26) GFW. Please let us know if you continue to have the issue. Thanks, -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:xen-ia64-devel- [EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: Friday, July 07, 2006 12:31 PM To: xen-ia64-devel Subject: [Xen-ia64-devel] VTi domain panic - use of invalid rid 4 It seems like if I run a domVTi long enough, I always hit the use of invalid rid 4 panic in vmx_vcpu_set_rr(). Has anyone else seen this? It happens after a while when I build a kernel in the VTi domain or when I try to do an install directly to a VTi domain. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] vti networking problems?
Alex, There is GFW change needed to address upstream IRQ logic indirectly derived from ACPI. The new GFW will be sent out tomorrow. Thanks, -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: Thursday, July 06, 2006 8:41 AM To: Tian, Kevin Cc: xen-ia64-devel Subject: RE: [Xen-ia64-devel] vti networking problems? On Wed, 2006-06-28 at 14:07 +0800, Tian, Kevin wrote: Yes, we also observed such problem and have rooted caused the reason (new ACPI logic added to qemu). Solution is in progress... Hi Kevin, Any news on this? I'd like to make sure I add it back into my testing when it gets fixed. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Problems booting dom0
1. Boot your native kernel 2. "mount" command to find out your root device name 3. Put the device name of #2 in the append line of elilo.conf 4. you may also want to modify /etc/fstab of "LABEL=/" to "DeviceName in #2" if any From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rodrigo LordSent: Thursday, June 01, 2006 8:01 AMTo: xen-ia64-devel@lists.xensource.comSubject: [Xen-ia64-devel] Problems booting dom0 Hello!I`m with problems to load dom0:UDF-fs: No partition foundXFS: bad magic numberXFS: SB validate failedKernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,7)I`m using Debian Sarge 3.1 on an Itanium 2.I`m using "xlilo" (modified version to xen) to load my xen.My elilo.conf:image=vmlinux-2.6.16.13-xen0 label=xen vmm=xen.gz initrd=initrd-2.6.16.13-xen0.img read-only append="com2=57600,8n1 console=com2 sched=bvt dom0_mem=256M --nomca console=tty0 console=ttyS1,57600,8n1 root=/dev/sda7"ps: I`m not sure if append="com2=57600,8n1 console=com2 sched=bvt dom0_mem=256M --nomca console=tty0 console=ttyS1,57600,8n1 root=/dev/sda7" is the correct configuration to me...Thanks! ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Enable hash vtlb
Dan, I thought the whole point of this patch was to improve performance? As discussed long time before as well as proposed in Xen Summit as an option, Hash vTLB is mainly to address SMP scalability for lager system like Itanium. It may still matches current global VHPT performance in UP if take out vTLB's key fetaures for SMP. And if the patchset (or a subset of it) *doesn't* fix the gcc segmentation fault issue AND causes a performance degradation AND only fixes a theoretical bug, This sentence sounds like unless vTLB fixes gcc, it shouldn't be in :-) Somehow this is a fair call to the real purpose of the hash vTLB. vTLB is not meant to fix bug, it is to provide scalability feature, period! Please note the GCC issue is not introduced by vTLB , rather it has been there long ago! Community effort is definitely needed to nail this sneaky bug introduced long ago. it should be applied now as it changes enough fundamental hypervisor code that it is reasonable to expect that it may introduce other subtle bugs. As the project goes, we should really decide a patch base on if it is architecturally needed to support Xen/IPF to achieve its best system performance, not base on if it changes fundermental code or not! If a design is needed, a short-term pain in addressing bugs is better than long-term unaddressed issues. ___ 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] Enable hash vtlb
As the project goes, we should really decide a patch base on if it is architecturally needed to support Xen/IPF to achieve its best system performance, not base on if it changes fundermental code or not! If a design is needed, a short-term pain in addressing bugs is better than long-term unaddressed issues. Agreed. I am discussing tradeoffs of performance vs stability vs functionality. On our current aggressive schedule, I would place networking functionality above stability, but I wouldn't place hugetlb functionality or huge SMP performance above stability. Others may disagree. Again, it is not fair to hint vTLB will introduce new bugs compares to the existing global VHPT implementation. Can the community share your agreesive schedule view here? Sounds everything needs to be serialized and take a small step a time! ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] RE: PATCH: PAL_VM_SUMMARY and PAL_VM_INFO
Wondering if there will be yet another OS got para-virtualized to run on Xen/IPF. Though supporting para-virtualized OS, we should continue to maintain a complete and minimal architectural instead of creating yet another legacy architecture. Or a new driver in XenLinux to take advantage of this pkrs. 16pkrs would be necessary for architectural completeness. -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magenheimer, Dan (HP Labs Fort Collins) Sent: Thursday, April 06, 2006 1:26 PM To: Williamson, Alex (Linux Kernel Dev) Cc: xen-ia64-devel@lists.xensource.com; Tristan Gingold Subject: [Xen-ia64-devel] RE: PATCH: PAL_VM_SUMMARY and PAL_VM_INFO From: Williamson, Alex (Linux Kernel Dev) Sent: Thursday, April 06, 2006 2:06 PM To: Magenheimer, Dan (HP Labs Fort Collins) Cc: Tristan Gingold; xen-ia64-devel@lists.xensource.com Subject: RE: PATCH: PAL_VM_SUMMARY and PAL_VM_INFO On Thu, 2006-04-06 at 09:30 -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote: max_pkr should probably be zero for now (at least non-VT) since pkr's are not implemented. Or would this be an illegal value because of architectural definition. Looks like that could be considered illegal, the SDM says there are at least 16 PKRs. Given that PKRs are currently unimplemented, returning an illegal value (0) might be the right thing anyway. Dan ___ 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] Fix vti domain qemu break issue
Xiantao, This patch should only for community reference. This code shouldn't be checked upstream due to it changes common code and it is only a tempory solution before VNIF/P2M from Isaku is ready. -Fred Zhang, Xiantao wrote: Sorry for forgetting last mail's subject. Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2006年3月22日 14:19 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] (no subject) This patch fixes VTI domain breaking issue caused by cset 9231. Root cause: cset 9231 save the ioemu vnif info into the xenstore, which cause control panel to wait for the VNIF backend device. Unfortunately, ia64 dom0 vnif backend is not ready currently due to the p2m issue. In this case, control panel will get VNIF timeout error and stop domain creation. What patch do: Since vnif backend will not be ready soon, this patch bypass this issue by adding backend=no option in control panel. When ia64 dom0 vnif backend is ready, we can safely remove this patch. Thanks -Xiantao ___ 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] Build Boot Dom0 for Tiger4 system
Know-How to Build boot Domain0 on a same Tiger4 system
1. Requirements -
a. Tiger4 system with Disk size more than 40GB, better to have 60GB
b. IA64 Linux RHEL4 Update2
c. Perform all the following operations in SuperVisor mode
2. Preparing target tiger4 system
a. Install complete RHEL4U2 disk by customize install
everything
b. Check to have SDL installed
rpm -q -a | grep SDL
SDL-1.2.7-8 SDL-devel-1.2.7-8
3. Download and install mercurial HG tool from
http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall
tar xvzf mercurial-0.7.tar.gz
cd mercurial-0.7
python setup.py install
Note: XenBuild.sh (Xen building) depends mercurial-0.7 version c.
4. Download and Build Xen
goto your prefer local directory To build
Modify XenBuild.sh to reflect your local proxy server
export http_proxy=http://proxy.xxx.yyy.com:911
XenBuild.sh or XenBuild.sh Cset# (XenBuild.sh see end of the
mail)
5. Add elilo Xen entry
Add following config to end of /boot/efi/efi/redhat/elilo.conf
image=vmlinux-2.6-xen0.gz
label=xen
vmm=xen.gz
initrd=initrd-2.6-xen0.img
read-only
append=com2=57600,8n1 console=com2 sched=bvt --
nomca console=tty0 console=ttyS1,57600 root=/dev/sda3
(root=/dev/sda3 should match
with local disk with mount command)
6. Copy Xen-enabled elilo.conf
cp ~/XenTree/xen/arch/ia64/tools/xelilo/xlilo.efi
/boot/efi/efi/redhat/elilo.efi
or you can keep the original elilo.efi for legacy Linux
boot and use xlilo xen for Xen boot only
7. Domain0 Boot
EFI Shell cd efi\redhat
EFI Shell xlilo xen
= XenBuild.sh
XenTree=$1
${XenTree:=tip}
echo $XenTree
XenHome=`pwd`
XenPath=$XenHome/$XenTree
echo Build place $XenPath
echo XenHome $XenHome
echo checking out code for $XenTree
rm -rf $XenTree
export http_proxy=http://proxy.xxx.yyy.com:911
hg clone http://xenbits.xensource.com/ext/xen-ia64-unstable.hg $XenTree
cd $XenTree
hg co $XenTree
make clean
make world
make install-tools
rm -rf /boot/efi/efi/redhat/xen.gz
rm -rf /boot/efi/efi/redhat/vmlinux-2.6.16-rc5-xen0
rm -rf /boot/efi/efi/redhat/vmlinux-2.6.16-rc5-xen0.gz
cp -f xen/xen.gz /boot/efi/efi/redhat
cp -f linux-2.6.16-rc5-xen0/vmlinux
/boot/efi/efi/redhat/vmlinux-2.6-xen0
cp -f linux-2.6.16-rc5-xen0/vmlinux.gz
/boot/efi/efi/redhat/vmlinux-2.6-xen0.gz
cd linux-2.6.16-rc5-xen0
make modules_install
/sbin/mkinitrd -f /boot/efi/efi/redhat/initrd-2.6-xen0.img
2.6.16-rc5-xen0 --builtin mptbase --builtin mptscsih
Sync;sync
cd $XenHome/$XenTree
export PATH=/usr/local/sbin:/usr/sbin:$PATH
cd dist
./install.sh
echo Please double check if any error from this install
sync;sync
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275
KangKang, What that means is you have to run both Xen and XenLinux (both Xen0 XenU) built from the same Cset#. -Fred You, Yongkang wrote: Hi Alex, I am not very clear about the new Xen image and the old xenlinux kernel standard for. Does xenlinux kernel mean xenU kernel? Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006年3月17日 4:29 To: xen-ia64-devel Subject: [Xen-ia64-devel] update linux kernels w/ xen-ia64 cset 9275 Please note, xen-ia64 cset 9275 will break functionality if a new xen images is used with an old xenlinux kernel. Please be sure to update your xenlinux image. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] XEN: accelerate guest tr search.
Xu, Anthony wrote: 3) I think we should be very careful about making changes that are intended to improve performance without doing any benchmarking. Many times I have seen code that was intended to improve performance actually -- surprise! -- result in performance degradation. Agree, but it's unpractical to let developer to do benchmark testing, Since Fujitsu will deliver regular performance reports, I think we could depend on these reports to find out the patch which cause performance degradation. The correct approach is to get all the necessary features in, and then do the system-wide benchmark and fine-tuning, rather than local tweak or small benchmarks for large scaled system like Itanium -Fred ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] CONFIG_DOMAIN0_CONTIGUOUS in domain.c
I believe Isaku can do P2M conditional build, ie. Add #if P2M #else ... for the existing build. Once he got code in, people can start utilize the code for stablizing. P2M can be gone after that. -Fred Magenheimer, Dan (HP Labs Fort Collins) wrote: This isn't a performance issue. I don't think domain0/U will function correctly with CONFIG_...CONTIGUOUS undef'd until all of Isaku's necessary VP+DMA changes (in Xen, Xenlinux, Xen drivers, and possibly tools) are complete. -Original Message- From: Dong, Eddie [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 28, 2006 4:19 PM To: Magenheimer, Dan (HP Labs Fort Collins); Tian, Kevin; Isaku Yamahata Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] CONFIG_DOMAIN0_CONTIGUOUS in domain.c Magenheimer, Dan (HP Labs Fort Collins) wrote: to VP. HOWEVER... it may be possible and desirable for much of Isaku's work to support both VP and P==M. For non-I/O code, CONFIG_DOMAIN0_CONTIGUOUS could be used (or possibly renamed) to select VP or P==M at compile-time, at least until the conversion to VP+DMA is complete. This would allow at least some of Isaku's As if eventually we will remove this code, putting an compile option now is OK IMO. But I think the default one should be #undefed by some pre-cleanip patch now so that people can find issues earlier if there have. #undef this one can support no matter p==m or p!=m, while #define this can only support p==m. Yes maybe we will see 0.5% performance degradation with #undef, but this is a functionality must as we all go toward p!=m :-( After the whole p2m/VP patch comes out, we can then do more performance tuning :-) Eddie ___ 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: xen-ia64-mm
Horms, All the development should push to xen-unstable-ia64.hg. xen-ia64--unstable-Intel.hg tree absolving designs that may be different from xen-ia64-unstable tree. I am coordinating this tree. There is no need to create a new tree. After Xen Summit, community developers are developing code base on committed schedule cooperatively and come out solid SMP host and guest support infrastructure in the next couple months. Xen-ia64-unstabl-Intel.hg will absolve these code. Community welcome more contributors. -Fred I understand from my colleague Yamahata-san that one of the ideas that came out of the Xen Summit (which unfortunately I was not able to attend) was a proposal for an mm-like tree for ia64-xen. A tree that could stand between the bleeding-edge development and breakage, such as the VP+DMA work, and the current xen-ia64-unstable.hg and xen-unstable.hg trees. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] ia64 update for 2.6.16-rc2
Dan, Are you pushing XenLinux update directly to Xen-unstable.hg without updating Xen-ia64-unstable.hg? When will you update all these XenLinux as well as other patches into Xen-ia64-unstable.hg for xen-ia64-unstable.hg? Whole community also need to move to the new base. -Fred Alex Williamson wrote: Hi Christian, Here's a patch that updates ia64 to 2.6.16-rc2 on xen-unstable. This boots dom0 and domU on an rx2600. There were still several files that were accidentally reverted by the merge-ups (that weren't fixed by cset 8743). Those are included here with the 2.6.15 patch re-applied as well as changes between 2.6.15 and 2.6.16-rc2. Specifically, these are pal.h, processor.h and system.h. This patch also reverts changes to include/asm-ia64/hypercall.h and hypervisor.h from cset 8742. Thanks, Alex Signed-off-by: Alex Williamson [EMAIL PROTECTED] --- buildconfigs/linux-defconfig_xen0_ia64 | 101 + buildconfigs/linux-defconfig_xenU_ia64 | 96 --- linux-2.6-xen-sparse/arch/ia64/Makefile |7 - linux-2.6-xen-sparse/arch/ia64/kernel/entry.S |1 linux-2.6-xen-sparse/arch/ia64/kernel/head.S |2 linux-2.6-xen-sparse/arch/ia64/kernel/setup.c | 26 - linux-2.6-xen-sparse/include/asm-ia64/hypercall.h |4 linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h |4 linux-2.6-xen-sparse/include/asm-ia64/pal.h| 23 linux-2.6-xen-sparse/include/asm-ia64/processor.h |9 - linux-2.6-xen-sparse/include/asm-ia64/system.h | 27 ++--- 11 files changed, 192 insertions(+), 108 deletions(-) diff -r 57e6d7218427 buildconfigs/linux-defconfig_xen0_ia64 --- a/buildconfigs/linux-defconfig_xen0_ia64 Fri Feb 3 18:45:14 2006 +++ b/buildconfigs/linux-defconfig_xen0_ia64 Mon Feb 6 03:56:58 2006 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.15-xen0 -# Wed Feb 1 13:18:15 2006 +# Linux kernel version: 2.6.16-rc2-xen0 +# Mon Feb 6 02:48:43 2006 # # @@ -24,8 +24,6 @@ # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set -CONFIG_HOTPLUG=y -CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set @@ -35,8 +33,10 @@ CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y +CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y @@ -45,8 +45,10 @@ CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 +CONFIG_SLAB=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set # # Loadable module support @@ -170,6 +172,7 @@ CONFIG_ACPI_THERMAL=y CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set +CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_ACPI_CONTAINER=y @@ -247,16 +250,13 @@ # # CONFIG_NETFILTER_NETLINK is not set # CONFIG_NF_CONNTRACK is not set +# CONFIG_NETFILTER_XTABLES is not set # # IP: Netfilter Configuration # # CONFIG_IP_NF_CONNTRACK is not set # CONFIG_IP_NF_QUEUE is not set -# CONFIG_IP_NF_IPTABLES is not set -CONFIG_IP_NF_ARPTABLES=y -# CONFIG_IP_NF_ARPFILTER is not set -# CONFIG_IP_NF_ARP_MANGLE is not set # # Bridge: Netfilter Configuration @@ -272,6 +272,11 @@ # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set # CONFIG_ATM is not set CONFIG_BRIDGE=y # CONFIG_VLAN_8021Q is not set @@ -471,13 +476,7 @@ CONFIG_SCSI_QLOGIC_FC=y # CONFIG_SCSI_QLOGIC_FC_FIRMWARE is not set CONFIG_SCSI_QLOGIC_1280=y -CONFIG_SCSI_QLA2XXX=y -CONFIG_SCSI_QLA21XX=y -CONFIG_SCSI_QLA22XX=y -CONFIG_SCSI_QLA2300=y -CONFIG_SCSI_QLA2322=y -# CONFIG_SCSI_QLA6312 is not set -# CONFIG_SCSI_QLA24XX is not set +# CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set @@ -588,12 +587,14 @@ # CONFIG_DL2K is not set CONFIG_E1000=y # CONFIG_E1000_NAPI is not set +# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set +# CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set CONFIG_TIGON3=y @@ -707,12 +708,15 @@ CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_NONSTANDARD=y +# CONFIG_COMPUTONE is not set # CONFIG_ROCKETPORT is not set # CONFIG_CYCLADES is not set # CONFIG_DIGIEPCA is not set +# CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set # CONFIG_ISI is not set # CONFIG_SYNCLINKMP is not set +# CONFIG_SYNCLINK_GT is not set # CONFIG_N_HDLC is not set # CONFIG_SPECIALIX is not set #
[Xen-ia64-devel] RE: [Xen-devel] [BUNDLE] Testing a simpler inter-domain transport
Dan, From Xen summit, isn't it to be more P2M liked approach due to consideration on driver domain and domain0 needs to get P2M for VBD/VNIF? Don't remember there is decision on taking Hypercall only approach and dropped P2M table lookup. Any justification here? -Fred Magenheimer, Dan (HP Labs Fort Collins) wrote: (I'm sure you meant PPC *and* ia64 ;*) On just a quick skim, one thing to note: IIRC from the summit, domain0 and driver domains for neither PPC nor ia64 will have a p2m lookup table so a p2m translation will require a hypercall. So while virt_to_machine is cheap for domains on x86, it is not on PPC and ia64. If HYPERVISOR_share can take physical addresses instead of machine addresses (with Xen doing the phys_to_machine part of the translation), I think the code would work better for PPC and ia64, as well as better hide the virtual-physical-machine memory abstraction. Dan ___ 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
[Xen-ia64-devel] RE: [Xen-users] Itanium 64 Bit Support?!
Title: Itanium 64 Bit Support?! Community is now working on Xen for Itanium. We can get multiple Domains up withDomainUand VT-i (Itanium Virtualization Technology) domains up together already Please goto http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-develto subscribe development news for Itanium as well as contribute your effort. :-) -Fred From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, February 01, 2006 12:51 AMTo: [EMAIL PROTECTED]Subject: [Xen-users] Itanium 64 Bit Support?! Does anyone know if Xen is currently supporting Itanium on 64 Bit!? Thomas Diederich*** Boehringer Ingelheim Pharma GmbH Co.KG* A Informationsverarbeitung / Diplomant Systemtechnik* * Mail: [EMAIL PROTECTED]* Phone: +49 (0)6132/77-98151 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Floating-point software assist (FPSWA) on Xen-ia64
How about minic how native Linux does for FPSWA instead for Xen to handle extra FP stuff. Somehow the FPSWA information should be passed to Domains for them to map into their own address space. It seems Domain0 doesn't get FPSWA info, so will happen on DomainU. Somehow how FPSWA info got passed to native kernel should be understood, then Xen can also pass the info accordingly for Domains to map it. -Fred Magenheimer, Dan (HP Labs Fort Collins) wrote: OK, so no conflict with VT-I. I'm thinking the best non-VTI implementation for now will be to call fpswa from inside Xen. This will appear to guests as if all the complex floating point ops that were previously handled by FPSWA are now handled in hardware. The disadvantage of this approach is that uses of fpswa will not be able to be tracked and reported (as they are today in Linux/ia64) because the guest will never see them. Any comments? Dan -Original Message- From: Yang, Fred [mailto:[EMAIL PROTECTED] Sent: Thursday, January 26, 2006 2:37 PM To: Magenheimer, Dan (HP Labs Fort Collins); xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] Floating-point software assist (FPSWA) on Xen-ia64 For native, the platform firmware comes with build-in FPSWA. If there is a new FPSWA.efi presented in the disk, the firmware will drop its default FPSWA. For DomainVTI to run, there is a Guest Firmware (GFW), with default FPSWA build-in, presented to domain. -Fred There is Guest Firmware (GFW) used for DomainVTI. Magenheimer, Dan (HP Labs Fort Collins) wrote: Yongkang has discovered that some LTP tests fail because Xen/ia64 (non-VTI) does not support FPSWA. Non-support of FPSWA is a known problem that has been on the to-do list for some time: http://lists.xensource.com/archives/html/xen-devel/2004-12/msg 00382.html but this is the first time that it has been seen in real (test) usage. Yongkang says that the test works with VTI. How does VTI handle FPSWA? Is direct access to fpswa.efi provided to every domain or is fpswa.efi owned by the hypervisor and floating-point assist traps handled by Xen invisibly to domains? A couple of related questions: Is fpswa.efi re-entrant? Does fpswa.efi ever disable interrupts? I don't think this will be hard to fix, but it would be best if the implementation is consistent between VTI and non-VTI. Thanks, Dan ___ 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] Floating-point software assist (FPSWA) on Xen-ia64
My speculation calling FPSWA within Xen will lead to 1. Set FPSR accordingly to Domain kernel with Xen, and then Save and restore domain FP registers before/after calling FPSWA in Xen 2. ready to handle FP exceptions caused by FPSWA execution. Note Domain application can't be trusted so it can likely incure FP exception. Xen FP exception must also able to distinguish exception source in order to unwind stack to deliver to domain handler. Will one domain impact Xen stability? 3. If domains doesn't got passed with FPSWA info, can its FP handler able to handle exception delivered from Xen? 4. FP opcode fetch must be performed within Xen (likely within FPSWA) to get from domain application base on IIP. TLB miss may likely happen and Xen can't handle it. 5. Domain FPSWA usage time is charged to Xen in stead of itself Xen may not able to handle above issues cleanly :-) To minic native behavior, can we provide a single physical copy of FPSWA for whole system without coping for each new domain created? That is, each domain will be given extra, other than domain memory, physical block that contains the same FPSWA. The memory is then exported to domains through EFI descriptor or ELILO (Whatever the native method is) with guest physical. For P2M, domains will map the FPSWA using exported guest physical and then Xen will instead map with the same machine physical block for all the domains. The assumption here is domains won't write to FPSWA to clobber it otherwise Xen has to change mapping attribute. Domain destroy may need to perform special handling on this machine block, but it should be easy once we have page reference count implemented. -Fred Magenheimer, Dan (HP Labs Fort Collins) wrote: Mimic'ing the same way for native Linux is a lot more complicated because fpswa.efi is in machine memory. This is OK for current domain0 (V==P) but for P2M or VP, it would need to be copied into the guest physical space for each domU or multiply mapped somehow. I guess this is what your Guest Firmware does, but for paravirtualized guests it would have to be copied/mapped by Xen or a bunch of new P2M code would need to be added to Xenlinux. Your solution might still be the best longterm answer to maximize identical behavior to Linux, but paravirtualizing has some virtues... presenting a more fully functional virtual FPU (by completely hiding the FPSWA) could be beneficial for some users. So not a clear win either way... Dan -Original Message- From: Yang, Fred [mailto:[EMAIL PROTECTED] Sent: Thursday, January 26, 2006 5:58 PM To: Magenheimer, Dan (HP Labs Fort Collins); xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] Floating-point software assist (FPSWA) on Xen-ia64 How about minic how native Linux does for FPSWA instead for Xen to handle extra FP stuff. Somehow the FPSWA information should be passed to Domains for them to map into their own address space. It seems Domain0 doesn't get FPSWA info, so will happen on DomainU. Somehow how FPSWA info got passed to native kernel should be understood, then Xen can also pass the info accordingly for Domains to map it. -Fred Magenheimer, Dan (HP Labs Fort Collins) wrote: OK, so no conflict with VT-I. I'm thinking the best non-VTI implementation for now will be to call fpswa from inside Xen. This will appear to guests as if all the complex floating point ops that were previously handled by FPSWA are now handled in hardware. The disadvantage of this approach is that uses of fpswa will not be able to be tracked and reported (as they are today in Linux/ia64) because the guest will never see them. Any comments? Dan -Original Message- From: Yang, Fred [mailto:[EMAIL PROTECTED] Sent: Thursday, January 26, 2006 2:37 PM To: Magenheimer, Dan (HP Labs Fort Collins); xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] Floating-point software assist (FPSWA) on Xen-ia64 For native, the platform firmware comes with build-in FPSWA. If there is a new FPSWA.efi presented in the disk, the firmware will drop its default FPSWA. For DomainVTI to run, there is a Guest Firmware (GFW), with default FPSWA build-in, presented to domain. -Fred There is Guest Firmware (GFW) used for DomainVTI. Magenheimer, Dan (HP Labs Fort Collins) wrote: Yongkang has discovered that some LTP tests fail because Xen/ia64 (non-VTI) does not support FPSWA. Non-support of FPSWA is a known problem that has been on the to-do list for some time: http://lists.xensource.com/archives/html/xen-devel/2004-12/msg 00382.html but this is the first time that it has been seen in real (test) usage. Yongkang says that the test works with VTI. How does VTI handle FPSWA? Is direct access to fpswa.efi provided to every domain or is fpswa.efi owned by the hypervisor and floating-point assist traps handled by Xen invisibly to domains? A couple of related questions
[Xen-ia64-devel] Meeting Summary taken from Xen-ia64 Next Steps Discussion during Xen Summit
Xen-ia64 Community members, Following is the agreement/summary taken from Xen/ia64 Next Steps Discussion session held during Xen Summit at January 17, 2006. The items in http://www.xensource.com/files/xs0106_ia64_nextsteps_disc.pdf are fully discussed The Work session attendees had agreed following actions in order to move Xen/ia64 to the next stage, and the efforts will be started immediately. 1. Physical Memory support for Domain0 * PPC port has the similar P2M issue as Xen-ia64 * Group agreed P2M is the route to take, the detail implementation can be between P2M VP approaches to change XenLinux as less as possible * To merge P2M into mainline code may cause Xen-ia64-unstable to be buggy or unstable for a period of time. Since this is a must feature to go, we should merge the code and get community to work together to get system stablized * Fujitsu has been looking into this effort and will contribute this effort * To Enable P2M for Domain0 is must for Xen-ia64 and should be done early to enable VBD/VNIF driver domain to come 2. Memory enhancement for page reference count * this can possibly cause stability issue and affecting domain destory * This item is a must for Xen-ia64 3. Virtual Interrupt Controller to let Xen owns physical IOSAPIC * This can help to address SMP guest for para-domains as well as a must for driver domain * a must item for xen-ia64 4. VTLB/VHPT SMP Support * To support next step SMP guest support, hash VTLB and same VHPT model should be adapted * A patch to extend hash VTLB/VHPT to hookup for para-virtualized Domain should be added Code should try to be built with option to able to pull original VHPT model back per future performance tunning needs * A must item for Xen/ia64 to get to SMP guest support 5. Reboot/Destroy Domains * A must item after page reference count is done 6. Hypercalls * Can be adapted per P2M and future needs 7. Timer Virtualization * This is defineitely worth to do to help the performance This summary lists major effort to overhaul overall Xen/ia64 infrastructure, we welcome developers to contribute into these efforts -Fred Yang ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
