Re: [Xen-ia64-devel] [Patch] Stop all cpus at panic time
Hi, Alex On Tue, 2007-12-04 at 23:48 +0900, Akio Takebe wrote: Hi, Current panic() of hypervisor doesn't stop all cpus. So domains can work after hypervisor panic. (but this issue happens at only using noreboot option) If dom0 works after Hypervisor panic, the system may get a serious problem. This looks like a good 3.2 candidate. I think there's still a minor issue though. Our implementation of stop_this_cpu() removes the CPU from the online map, disables interrupts, then returns(!). We should probably figure out if we still need the call to cpu_halt() ifdef'd out or at least put a busy loop in it's place. Thanks, Thank you for your review. It's a good point. I'm trying those choices. smp_send_stop is also used by kexec. I think it is important that INIT handler and kdump work fine at panic. I tried INIT handler at panic, but INIT handler didn't work. It seems to be a little broken. I'll debug it soon. 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] the xenLinux/IA64 upstream merge and Fedora.
Hi Stephen, Stephen C. Tweedie wrote: [Wed Dec 05 2007, 12:52:30PM EST] Hi, On Wed, 2007-12-05 at 12:26 -0500, Aron Griffis wrote: http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg Does Fedora have any forward ported tree? This question is probably best answered by Stephen. I think what we want is an x86 forward-ported tree so we can see how the generic bits change. Then it's just a matter of making arch/ia64 changes to accomodate, right? Nononono! The entire point of our exercise is to avoid forward-porting, as forward-porting is becoming increasingly burdensome and error-prone as the upstream Linux tree diverges from the 2.6.18 xen-unstable tree. The Linus 2.6.24 tree already has pv_ops in it, with Xen support, for i686. Forward-porting the 2.6.18 tree just means trying to squeeze the old-style Xen hooks into a tree that already has completely different virtualisation hooks in it. So our effort here is specifically NOT to forward-port the whole of Xen, but to use the 2.6.24 pv_ops as a starting point, and merge into it ONLY the selected bits from 2.6.18 that pv_ops does not yet have (such as dom0 support.) Sorry, what you're saying is what I intended. By x86 forward-ported tree I meant x86 pv_ops tree. For ia64 there is still a question of how we'll use pv_ops. We already have the machine vector which provides something similar. Yamahata-san also has a binary-patching pv_ops alternative which might work better on ia64 than the stock pv_ops. As an experiment, I started a merge of arch/ia64 to v2.6.23. One of the main goals here is to reduce the effort of keeping a full Xen tree in sync with upstream (ideally, with the long-term goal of getting things fully merged, although that may not be completely practical for everything that Xen does.) So, rather than just merging 2.6.18-xen's existing stuff into 2.6.23/24, we should probably be trying to follow what i386 did in pv_ops, and getting a pv_ops-based ia64 implementation to build on. There's a good chance of getting that into the upstream kernel (at least for domU, which is where we're at on i686 upstream too), which will help the long-term maintainability no end. Depending on how ia64 uses pv_ops, the code in arch/ia64 could look somewhat *similar* to what we have now, albeit cleaned up, moved around and submitted piecemeal upstream. My forward merge was just to see how badly it would conflict with current linux/ia64 code, not because I was thinking that was the correct path. So if xenlinux/ia64 is merged into kernel.org, would we then concentrate all our kernel efforts on that tree and eventually abandon linux-2.6.18-xen.hg? Absolutely, our goal is never to have another linux-2.6.18-xen.hg-based tree in Fedora again --- we want to rebuilt a new tree based on what's upstream in 2.6.24, which will probably have to be git-based to stay close to upstream as efficiently as possible. I know this is a rhetorical question, but it seems like it would be better to concentrate on the current tree in the future, rather than needing to forward port changes continuously. If by current tree you mean the Linus upstream as opposed to the aging XenSource 2.6.18, then yes, that's exactly what we're trying to achieve here. Right, that's what I meant. Sorry for the unclear terms. :-( Thanks, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch 00/12] Kexec: EFI Mapping: Take IV
Hi Simon, So there's really nothing special to reproduce the SAL problem. I reproduced it first try on a zx2000. I imagine any of the first generation HP Itanium 2 boxes with latest firmware will hit it. This includes: rx2600, zx6000, and zx2000 with firmware 2.31. I can set one up if you can't find one. I've only gone so far as to verify that the sal_proc entry point does live in a runtime mapping, EFI SetVirtualAddressMap returns success, and decoding the status returned by the SAL calls. The status is quite strange and makes me wonder what code I'm jumping into; I get this: 0xe0003f93. I got the same value back for a few SAL calls. I wish I had an ITP hooked up to a system doing this so we could watch where it's going. The problem only shows up when the relocation is activated by the last kexec patch, so it's not an intermediate patch inadvertently doing something extra. Let me know if you have any thoughts on how to debug this. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Xen/IA64 Healthiness Report -- Cset #16540
Xen/IA64 Healthiness Report --- Cset #16540 = Test Result Summary: In this lightly validation for Cset# 16540, neither linux nor window guest HVM could be created by using latest open guest firmware. Fortunately, switching to use Intel guest firmware with -c option of xm create command can avoid this problem. To keep the auto lightly validation workable, the combination of Intel guest firmware and -c option will be used as workaround for next lightly validations of new Csets until the above problem is removed. # total case: 18 # passed case:18 # failed case: 0 = Testing Environment: platform: Tiger4 processor: Itanium 2 Processor logic Processors number: 8 (2 processors with Dual Core) pal version: 9.08 service os: RHEL4u3 IA64 SMP with 2 VCPUs vti guest os: RHEL4u2 RHEL4u3 xenU guest os: RHEL4u2 xen ia64 unstable tree: 16540 xen schedule: credit gfw: Intel Guest Firmware (2007-06-28) = Detailed Test Results: Passed case id Description SaveRestoreSaveRestore PV IPF PV Two_UP_VTI_Co2 UP_VTI (mem=256) One_UP_VTI 1 UP_VTI (mem=256) One_UP_XenU 1 UP_xenU(mem=256) SMPVTI_LTP VTI (vcpus=4, mem=512) run LTP SMPVTI_and_SMPXenU 1 VTI + 1 xenU (mem=256 vcpus=2) Two_SMPXenU_Coexist 2 xenU (mem=256, vcpus=2) One_SMPVTI_4096M1 VTI (vcpus=2, mem=4096M) SMPVTI_Network 1 VTI (mem=256,vcpu=2) and 'ping' SMPXenU_Network 1 XenU (vcpus=2) and 'ping' One_SMP_XenU1 SMP xenU (vcpus=2) One_SMP_VTI 1 SMP VTI (vcpus=2) SMPVTI_Kernel_Build VTI (vcpus=4) and do Kernel Build Four_SMPVTI_Coexist 4 VTI domains( mem=256, vcpu=2) SMPVTI_Windows SMPVTI windows(vcpu=2) SMPWin_SMPVTI_SMPxenU SMPVTI Linux/Windows XenU UPVTI_Kernel_Build 1 UP VTI and do kernel build Failed case id Description N/A = Notes: The last stable changeset: 16477 = Best Regards, Amy, Mu ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [IA64] Weekly benchmark results [ww49]
Hi, I report a benchmark result of this week on IPF using ia64/xen-unstable and ia64/linux-2.6.18-xen. All test cases passed. TEST ENVIRONMENT Machine : Tiger4 Kernel : 2.6.18.8-xen Changeset: 16540:8ba08f2244b2 (ia64/xen-unstable) 337:4108b5c64f86 (ia64/linux-2.6.18-xen) 35:ebf7052731ec(efi-vfirmware) Dom0 OS : RHEL4 U2 (2P) DomU OS : RHEL4 U2 (8P, using tap:aio) DomVTi OS: RHEL4 U2 (8P, with PV-on-HVM drivers) Scheduler: credit TEST RESULT DomU: unixbench4.1.0: Pass bonnie++-1.03 : Pass ltp-full-20070930 : Pass iozone3_191 : Pass lmbench-3.0-a5: Pass DomVTi: unixbench4.1.0: Pass bonnie++-1.03 : Pass ltp-full-20070930 : Pass iozone3_191 : Pass lmbench-3.0-a5: Pass Best regards, KUWAMURA and Fujitsu members ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
