[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
[Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11824
Xen/IA64 Healthiness Report VTI Windows creation failure has been fixed in latest changeset. SMP VTI hang Xen0 issue has been fixed in latest changeset. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core) PAL version: 8.15 Service OS: RHEL4u3 IA64 SMP with 2 VCPUs VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 11824:ee7799388ab1 Xen Schedule: credit VTI Guest Firmware MD5: ea1815932b91e5a6481bb64468e50254 Summary Test Report: - Total cases: 16 Passed:16 Failed: 0 Detailed test cases info: - 1. One_VTI_without_vifpass 2. One_VTI pass 3. One_XenU pass 4. Two_VTI_Coexist pass 5. One_VTI_and_One_XenU pass 6. Two_XenU_Coexist pass 7. One_VTI_4096M pass 8. VTI_Network pass 9. XenU_Network pass 10. One_SMP_XenU pass 11. One_SMP_VTIpass 12. UP_VTI_LTP pass 13. VTI_Kernel_Build pass 14. Four_VTI_Coexist pass 15. VTI_Windows pass 16. VTI_Win_Linux_XenU_Coexist pass Notes: - The last stable changeset: - 11824:ee7799388ab1 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] BUG at mm.c:605
Hi Alex,
Alex Williamson wrote:
Ok, should I simply revert xen-ia64-unstable cset 11636:3470d9cd27e5?
Basically, yes. But we can't avoid hypervisor crash during domain
destruction.
I think to modify above patch to remove VT-i domain checker like
attaced patch, until we will success to seek for the right fix.
This seems worse. Instead of having an identifiable crash footprint,
the system just hangs with this patch. Thanks,
I see. In this time, I inserted dump_stack() at the condition.
What do you think about it ?
Thanks
- Tsuneshisa Doi
Preliminary fix to avoid hypervisor crash during domain destruction
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r ee7799388ab1 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cWed Oct 18 22:07:18 2006 -0600
+++ b/xen/arch/ia64/xen/mm.cThu Oct 19 17:01:41 2006 +0900
@@ -399,11 +399,11 @@ gmfn_to_mfn_foreign(struct domain *d, un
unsigned long pte;
// This function may be called from __gnttab_copy()
- // during destruction of VT-i domain with PV-on-HVM driver.
+ // during domain destruction with VNIF copy receiver.
// ** FIXME: This is not SMP-safe yet about p2m table. **
if (unlikely(d-arch.mm.pgd == NULL)) {
- if (VMX_DOMAIN(d-vcpu[0]))
- return INVALID_MFN;
+ dump_stack(); // collect footprint
+ return INVALID_MFN;
}
pte = lookup_domain_mpa(d,gpfn PAGE_SHIFT, NULL);
if (!pte) {
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: makes XEN virtual mapping more flexible
Le Jeudi 19 Octobre 2006 06:22, Alex Williamson a écrit : On Wed, 2006-10-18 at 11:53 +0200, Tristan Gingold wrote: Hi, By making xen virtual mapping more flexible I am able to run Xen within XenVTi. This is very useful to debug Xen and also to test the VTi code. Tested by running domU and domVTI. Hi Tristan, I get segfaults with this patch on both domVTI and domU. My RHEL4U3 VTI domain hit errors in the init scripts and my SMP domU couldn't complete a kernel compile. Thanks, Unfortunatly I confirm :-( Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [SMP_VTI] Create/destroy 2 SMP_VTI will make xen0 hang
Hi all, On Cset 11824, when I create/destroy 2 SMP_VTI for about 20 times, xen0 may hang. I did not get the serial port log. The reproducing way is very easy, just following these steps: 1. Create 2 SMP_VTI domains at the same time; 2. Wait 20 seconds (just a short time interval), note: Not let them boot up; 3. Destroy them and repeat from step1. Do the create/destroy operations for 20-30 times, xen0 will hang. Thanks, Zhangjingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Thanks!
Hi, before leaving Bull I'd like to thanks everyone. Thanks to HP for initiating Xen/ia64 and managing the project in a very democratic way. Thanks to Intel for bringing its OEM to Xen. Thanks to every contributors. The xen/ia64 community is small but very active. Xen/ia64 has made amazing progresses. If any thanks to those I have forgotten! If you need to reach me, my private email is [EMAIL PROTECTED] Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Thanks!
Hi Tristan, I have to say it's my pleasure to work with you. Your broad knowledge, smartness and kindness impressed everybody in this mailing list a lot. Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tristan Gingold Sent: 2006年10月19日 16:56 To: xen-ia64-devel Subject: [Xen-ia64-devel] Thanks! Hi, before leaving Bull I'd like to thanks everyone. Thanks to HP for initiating Xen/ia64 and managing the project in a very democratic way. Thanks to Intel for bringing its OEM to Xen. Thanks to every contributors. The xen/ia64 community is small but very active. Xen/ia64 has made amazing progresses. If any thanks to those I have forgotten! If you need to reach me, my private email is [EMAIL PROTECTED] Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: remove unused vmx/mm.c file.
Hi, this file is not used. Tested by compiling. Tristan. # HG changeset patch # User [EMAIL PROTECTED] # Node ID 79e2af384825b9ed8f742d64e39eb44f1c69a32f # Parent ee7799388ab14c0ad2c2e0ed02db37d2445b687a Remove unused file. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r ee7799388ab1 -r 79e2af384825 xen/arch/ia64/vmx/mm.c --- a/xen/arch/ia64/vmx/mm.c Wed Oct 18 22:07:18 2006 -0600 +++ /dev/null Thu Jan 01 00:00:00 1970 + @@ -1,153 +0,0 @@ -/** - * arch/ia64/mm.c - * - * Copyright (c) 2002-2005 K A Fraser - * Copyright (c) 2004 Christian Limpach - * Copyright (c) 2005, Intel Corporation. - * Xuefei Xu (Anthony Xu) ([EMAIL PROTECTED]) - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - */ - -/* - * A description of the x86 page table API: - * - * Domains trap to do_mmu_update with a list of update requests. - * This is a list of (ptr, val) pairs, where the requested operation - * is *ptr = val. - * - * Reference counting of pages: - * - * Each page has two refcounts: tot_count and type_count. - * - * TOT_COUNT is the obvious reference count. It counts all uses of a - * physical page frame by a domain, including uses as a page directory, - * a page table, or simple mappings via a PTE. This count prevents a - * domain from releasing a frame back to the free pool when it still holds - * a reference to it. - * - * TYPE_COUNT is more subtle. A frame can be put to one of three - * mutually-exclusive uses: it might be used as a page directory, or a - * page table, or it may be mapped writable by the domain [of course, a - * frame may not be used in any of these three ways!]. - * So, type_count is a count of the number of times a frame is being - * referred to in its current incarnation. Therefore, a page can only - * change its type when its type count is zero. - * - * Pinning the page type: - * -- - * The type of a page can be pinned/unpinned with the commands - * MMUEXT_[UN]PIN_L?_TABLE. Each page can be pinned exactly once (that is, - * pinning is not reference counted, so it can't be nested). - * This is useful to prevent a page's type count falling to zero, at which - * point safety checks would need to be carried out next time the count - * is increased again. - * - * A further note on writable page mappings: - * - - * For simplicity, the count of writable mappings for a page may not - * correspond to reality. The 'writable count' is incremented for every - * PTE which maps the page with the _PAGE_RW flag set. However, for - * write access to be possible the page directory entry must also have - * its _PAGE_RW bit set. We do not check this as it complicates the - * reference counting considerably [consider the case of multiple - * directory entries referencing a single page table, some with the RW - * bit set, others not -- it starts getting a bit messy]. - * In normal use, this simplification shouldn't be a problem. - * However, the logic can be added if required. - * - * One more note on read-only page mappings: - * - - * We want domains to be able to map pages for read-only access. The - * main reason is that page tables and directories should be readable - * by a domain, but it would not be safe for them to be writable. - * However, domains have free access to rings 1 2 of the Intel - * privilege model. In terms of page protection, these are considered - * to be part of 'supervisor mode'. The WP bit in CR0 controls whether - * read-only restrictions are respected in supervisor mode -- if the - * bit is clear then any mapped page is writable. - * - * We get round this by always setting the WP bit and disallowing - * updates to it. This is very unlikely to cause a problem for guest - * OS's, which will generally use the WP bit to simplify copy-on-write - * implementation (in that case, OS wants a fault when it writes to - * an application-supplied buffer). - */ - -#include xen/config.h -//#include public/xen.h -#include xen/init.h -#include xen/lib.h -#include xen/mm.h -#include xen/errno.h -#include asm/vmx_vcpu.h -#include asm/vmmu.h -#include asm/regionreg.h -#include asm/vmx_mm_def.h -/* -
Re: [Xen-ia64-devel] Thanks!
Hi Tristan, Thank you for many advices and suggestion. I've been fortunate to have good time to work with you. You (Tristan.Gingold) said: Hi, before leaving Bull I'd like to thanks everyone. Thanks to HP for initiating Xen/ia64 and managing the project in a very democratic way. Thanks to Intel for bringing its OEM to Xen. Thanks to every contributors. The xen/ia64 community is small but very active. Xen/ia64 has made amazing progresses. If any thanks to those I have forgotten! If you need to reach me, my private email is [EMAIL PROTECTED] Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Thanks!
On Thu, 2006-10-19 at 10:56 +0200, Tristan Gingold wrote: Thanks to every contributors. The xen/ia64 community is small but very active. Xen/ia64 has made amazing progresses. Tristan, You've played a huge part in our progress. Thank you for all your contributions! I hope that we'll see you again even after you've left Bull. 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] Thanks!
On Thu, 2006-10-19 at 10:56 +0200, Tristan Gingold wrote: before leaving Bull I'd like to thanks everyone. And I would like to thank you -- your contributions have been enormous. I wish you the best of luck in whatever you do next! -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Thanks!
Tristan Gingold wrote: [Thu Oct 19 2006, 04:56:24AM EDT] before leaving Bull I'd like to thanks everyone. Tristan, thank you for helping out to get xen/ia64 into Fedora! Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
