Re: [Xen-ia64-devel] Compiling error: libxc
Hi Tristan! I'm just a xen tester, not a programmer! :) Can you get me more details? Thanks! 2007/3/21, Tristan Gingold [EMAIL PROTECTED]: On Tue, Mar 20, 2007 at 05:37:04PM -0300, Rodrigo Lord wrote: I don't know how to see the change-set in the ia64 version (in the x86, I saw the archive Changelog)... I have installed the xen-ia64 some time ago, and it's ok... but now, I installed a new change-set and it doesn't work! (libxc problem) :( I tryied to install a patch to libxc, but it failed too... Any suggestion? I hqve the same issue on my system (debian based). It is a conflict between a system header (elf.h IIRC) and a xen header. Simply manually edit the xen header to remove the error. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] Improve error message when HVM domain creation failed
On Wed, 2007-03-21 at 20:05 +0900, Masaki Kanno wrote: This patch changes the return value of the following functions to -12(ENOMEM). Therefore the error message is changed to Cannot allocate memory. - vmx_final_setup_guest() - init_domain_tlb() - init_domain_vhpt() Applied. 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] Xen summit
On Thu, Mar 22, 2007 at 04:05:23PM -0600, Alex Williamson wrote: Who's going to Xen Summit? I'm planning to go. Should we try to carve out some time for a Xen/ia64 get together? Thanks, It would be valuable. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen summit
Alex Williamson write on 2007年3月23日 6:05: Hi All, Who's going to Xen Summit? Should we try to carve out some time for a Xen/ia64 get together? Thanks, Alex I won't be there this time. - Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] fix the ia64 p2m semantic
Make the semantic same as the x86 one. So far the ia64 p2m has the semantic similar to (the x86 p2m) + (page reference count). But the differece from the x86 p2m have caused the breakage and work around. This patch make the ia64 p2m semantic same as x86 to solve it. - get_page() only for grant table page mapping and foreign domain page mapping. - put_page() only for those pages. - guest_physmap_remove_page() doesn't touch PGC_allocated bit. I have to admit this patch is ugly. There's much room for clean up, especially get_page() right before put_page(). But they aren't on performance critical path (memory exchange and decrease reservation). I'm rushing because I want to push this into 3.0.5. Tsunehisa. I haven't tested arch_memory_op(). Could you verify it? -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] remove the ia64 p2m bug work around
The ia64 p2m semantic is now fixed. remove unnecessary work around patch.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1174568114 -32400
# Node ID eaeeefd8cddb55016ccd10e4d8b56db71963e67c
# Parent d1bd4110c3b1406594ec3a638371f0e72568bf3f
The ia64 p2m semantic is now fixed. remove unnecessary work around patch.
PATCHNAME: remove_work_round
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r d1bd4110c3b1 -r eaeeefd8cddb linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Fri Mar 23 11:29:36 2007 +0900
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Thu Mar 22 21:55:14 2007 +0900
@@ -205,18 +205,6 @@ static void contiguous_bitmap_clear(
#define MAX_CONTIG_ORDER 7
static unsigned long discontig_frames[1MAX_CONTIG_ORDER];
-/* Width of DMA addresses. 30 bits is a b44 limitation. */
-#define DEFAULT_DMA_BITS 30
-static unsigned int xen_ia64_dma_bits = DEFAULT_DMA_BITS;
-
-static int __init
-setup_dma_bits(char *str)
-{
- xen_ia64_dma_bits = simple_strtoul(str, NULL, 0);
- return 0;
-}
-__setup(xen_ia64_dma_bits=, setup_dma_bits);
-
/* Ensure multi-page extents are contiguous in machine memory. */
int
__xen_create_contiguous_region(unsigned long vstart,
@@ -245,15 +233,6 @@ __xen_create_contiguous_region(unsigned
},
.nr_exchanged = 0
};
-
- /*
- * XXX xen/ia64 vmm bug work around
- * the c/s 13366:ed73ff8440d8 of xen-unstable.hg revealed that
- * XENMEM_exchange has been broken on Xen/ia64.
- * This is work around for it until the right fix.
- */
- if (address_bits xen_ia64_dma_bits)
- return -ENOSYS;
if (unlikely(order MAX_CONTIG_ORDER))
return -ENOMEM;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] fix the ia64 p2m semantic
forgot to attach the patch.
On Fri, Mar 23, 2007 at 11:38:34AM +0900, Isaku Yamahata wrote:
Make the semantic same as the x86 one.
So far the ia64 p2m has the semantic similar to
(the x86 p2m) + (page reference count).
But the differece from the x86 p2m have caused the breakage and work around.
This patch make the ia64 p2m semantic same as x86 to solve it.
- get_page() only for grant table page mapping and foreign domain page
mapping.
- put_page() only for those pages.
- guest_physmap_remove_page() doesn't touch PGC_allocated bit.
I have to admit this patch is ugly.
There's much room for clean up, especially get_page() right before put_page().
But they aren't on performance critical path (memory exchange and
decrease reservation).
I'm rushing because I want to push this into 3.0.5.
Tsunehisa.
I haven't tested arch_memory_op(). Could you verify it?
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1174616976 -32400
# Node ID d1bd4110c3b1406594ec3a638371f0e72568bf3f
# Parent be1017157768e8d6d5d5552cf0008d81d611b1bb
Make the semantic same as the x86 one.
So far the ia64 p2m has the semantic similar to
(the x86 p2m) + (page reference count).
But the differece from the x86 p2m have caused the breakage and work around.
This patch make the ia64 p2m semantic same as x86 to solve it.
- get_page() only for grant table page mapping and foreign domain page
mapping.
- put_page() only for those pages.
- guest_physmap_remove_page() doesn't touch PGC_allocated bit.
PATCHNAME: fix_p2m_semantic
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r be1017157768 -r d1bd4110c3b1 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Thu Mar 22 09:30:54 2007 -0600
+++ b/xen/arch/ia64/xen/mm.c Fri Mar 23 11:29:36 2007 +0900
@@ -208,46 +208,6 @@ alloc_dom_xen_and_dom_io(void)
BUG_ON(dom_io == NULL);
}
-// heavily depends on the struct page_info layout.
-// if (page_get_owner(page) == d
-// test_and_clear_bit(_PGC_allocated, page-count_info)) {
-// put_page(page);
-// }
-static void
-try_to_clear_PGC_allocate(struct domain* d, struct page_info* page)
-{
-u32 _d, _nd;
-u64 x, nx, y;
-
-_d = pickle_domptr(d);
-y = *((u64*)page-count_info);
-do {
-x = y;
-_nd = x 32;
-nx = x - 1;
-__clear_bit(_PGC_allocated, nx);
-
-if (unlikely(!(x PGC_allocated)) || unlikely(_nd != _d)) {
-struct domain* nd = unpickle_domptr(_nd);
-if (nd == NULL) {
-gdprintk(XENLOG_INFO, gnttab_transfer:
-Bad page %p: ed=%p(%u) 0x%x,
-sd=%p 0x%x,
- caf=%016lx, taf=% PRtype_info \n,
-(void *) page_to_mfn(page),
-d, d-domain_id, _d,
-nd, _nd,
-x,
-page-u.inuse.type_info);
-}
-break;
-}
-
-BUG_ON((nx PGC_count_mask) 1);
-y = cmpxchg((u64*)page-count_info, x, nx);
-} while (unlikely(y != x));
-}
-
static void
mm_teardown_pte(struct domain* d, volatile pte_t* pte, unsigned long offset)
{
@@ -267,22 +227,25 @@ mm_teardown_pte(struct domain* d, volati
if (!mfn_valid(mfn))
return;
page = mfn_to_page(mfn);
-// struct page_info corresponding to mfn may exist or not depending
-// on CONFIG_VIRTUAL_FRAME_TABLE.
-// This check is too easy.
-// The right way is to check whether this page is of io area or acpi pages
+// page might be pte page for p2m exposing. check it.
if (page_get_owner(page) == NULL) {
BUG_ON(page-count_info != 0);
return;
}
+// struct page_info corresponding to mfn may exist or not depending
+// on CONFIG_VIRTUAL_FRAME_TABLE.
+// The above check is too easy.
+// The right way is to check whether this page is of io area or acpi pages
if (pte_pgc_allocated(old_pte)) {
BUG_ON(page_get_owner(page) != d);
BUG_ON(get_gpfn_from_mfn(mfn) == INVALID_M2P_ENTRY);
set_gpfn_from_mfn(mfn, INVALID_M2P_ENTRY);
-try_to_clear_PGC_allocate(d, page);
-}
-put_page(page);
+if (test_and_clear_bit(_PGC_allocated, page-count_info))
+put_page(page);
+} else {
+put_page(page);
+}
}
static void
@@ -770,7 +733,6 @@ __assign_new_domain_page(struct domain *
{
struct page_info *p;
unsigned long maddr;
-int ret;
BUG_ON(!pte_none(*pte));
@@ -791,8 +753,6 @@ __assign_new_domain_page(struct domain *
maddr);
}
-ret = get_page(p, d);
-BUG_ON(ret == 0);
set_gpfn_from_mfn(page_to_mfn(p), mpaddr PAGE_SHIFT);
// clear_page() and set_gpfn_from_mfn() become visible before
[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
[Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#14513
Xen/IA64 Healthiness Report Only the Two_SMPXenU_Coexist case in this Cset have failed. But it passed in manual test. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core) PAL version: 8.47 Service OS: RHEL4u3 IA64 SMP with 2 VCPUs VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 14513:be1017157768 Xen Schedule: credit VTI Guest Firmware Flash.fd.2006.12.01 MD5: 09a224270416036a8b4e6f8496e97854 Summary Test Report: - Total cases: 16 Passed: 15 Failed: 1 Case Name Status Case Description Four_SMPVTI_Coexist pass 4 VTI (mem=256, vcpus=2) Two_UP_VTI_Co pass 2 UP_VTI (mem=256) One_UP_VTI pass 1 UP_VTI (mem=256) One_UP_XenU pass 1 UP_xenU(mem=256) SMPVTI_LTP pass VTI (vcpus=4, mem=512) run LTP SMPVTI_and_SMPXenU pass 1 VTI + 1 xenU (mem=256 vcpus=2) Two_SMPXenU_Coexist fail 2 xenU (mem=256, vcpus=2) One_SMPVTI_4096M pass 1 VTI (vcpus=2, mem=4096M) SMPVTI_Network pass 1 VTI (mem=256,vcpu=2) and 'ping' SMPXenU_Network pass 1 XenU (vcpus=2) and 'ping' One_SMP_XenU pass 1 SMP xenU (vcpus=2) One_SMP_VTI pass 1 SMP VTI (vcpus=2) SMPVTI_Kernel_Build pass VTI (vcpus=4) and do Kernel Build Four_SMPVTI_Coexist pass 4 VTI domains( mem=256, vcpu=2) SMPVTI_Windows pass SMPVTI windows(vcpu=2) SMPWin_SMPVTI_SMPxenU pass SMPVTI Linux/Windows XenU UPVTI_Kernel_Build pass 1 UP VTI and do kernel build Notes: - The last stable changeset: - 14494:2216a45bf058 Best Regards Liuqing ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
