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
[Xen-ia64-devel] XenU will crash Xen in CSet # 13773.
Hi all, In latest Changeset 13773, if creating XenU, Xen0 would crash and hang. The hang happened when XenU try to bring up its network. The serial console log is attached. BTW. VTI domain creation also meets a little issue, which is brought from xen-unstable. If try to create VTI domain with sdl=1, VTI window won't popup. Edwin has sent a patch to xen-devel to fix it. The simple workaround is to use vnc to create VTI domain. No detailed testing report today. Best Regards, Yongkang (Kangkang) 永康 xen_crash.log Description: xen_crash.log ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] new domain builder setup hook clean up (was Re: [Xen-devel] [PATCH] new domain builder fix to boot domU on IA64.)
On Thu, Feb 01, 2007 at 08:59:33AM +0100, Gerd Hoffmann wrote:
Hmm, bootearly() is called twice now, I guess the first call in
mem_init() should have been removed? Otherwise the patch looks fine to me.
Yes. Thanks for pointing out.
Attaced updated one.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1170329925 -32400
# Node ID 72fa33b455d1058f15caabab1aafe6ea27fcdb43
# Parent 3751a96ba0217690b4f1fedc577ed4d45a7b456e
new domain builder arch_setup hook clean up.
arch_setup_early - arch_setup_meminit
arch_setup_middle - arch_setup_bootearly
arch_setup_late - arch_setup_bootlate
PATCHNAME: new_domain_builder_cleanup
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 3751a96ba021 -r 72fa33b455d1 tools/libxc/xc_dom_boot.c
--- a/tools/libxc/xc_dom_boot.c Thu Feb 01 11:50:48 2007 +0900
+++ b/tools/libxc/xc_dom_boot.c Thu Feb 01 20:38:45 2007 +0900
@@ -144,7 +144,7 @@ static int x86_shadow(int xc, domid_t do
return rc;
}
-static int arch_setup_early(struct xc_dom_image *dom)
+static int arch_setup_meminit(struct xc_dom_image *dom)
{
int rc = 0;
@@ -157,13 +157,13 @@ static int arch_setup_early(struct xc_do
return rc;
}
-static int arch_setup_middle(struct xc_dom_image *dom)
-{
-xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
-return 0;
-}
-
-static int arch_setup_late(struct xc_dom_image *dom)
+static int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
+return 0;
+}
+
+static int arch_setup_bootlate(struct xc_dom_image *dom)
{
static const struct {
char *guest;
@@ -263,13 +263,13 @@ static int arch_setup_late(struct xc_dom
#elif defined(__ia64__)
-static int arch_setup_early(struct xc_dom_image *dom)
-{
-xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
-return 0;
-}
-
-static int arch_setup_middle(struct xc_dom_image *dom)
+static int arch_setup_meminit(struct xc_dom_image *dom)
+{
+xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
+return 0;
+}
+
+static int arch_setup_bootearly(struct xc_dom_image *dom)
{
DECLARE_DOMCTL;
int rc;
@@ -281,10 +281,6 @@ static int arch_setup_middle(struct xc_d
domctl.domain = dom-guest_domid;
domctl.u.arch_setup.flags = 0;
-/* dom-start_info_pfn should be initialized by alloc_magic_pages().
- * However it is called later. So we initialize here.
- */
-dom-start_info_pfn = dom-total_pages - 3;
domctl.u.arch_setup.bp = (dom-start_info_pfn PAGE_SHIFT)
+ sizeof(start_info_t);
/* 3 = start info page, xenstore page and console page */
@@ -293,7 +289,7 @@ static int arch_setup_middle(struct xc_d
return rc;
}
-static int arch_setup_late(struct xc_dom_image *dom)
+static int arch_setup_bootlate(struct xc_dom_image *dom)
{
unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
shared_info_t *shared_info;
@@ -317,19 +313,19 @@ static int arch_setup_late(struct xc_dom
#elif defined(__powerpc64__)
-static int arch_setup_early(struct xc_dom_image *dom)
-{
-xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
-return 0;
-}
-
-static int arch_setup_middle(struct xc_dom_image *dom)
-{
-xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
-return 0;
-}
-
-static int arch_setup_late(struct xc_dom_image *dom)
+static int arch_setup_meminit(struct xc_dom_image *dom)
+{
+xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
+return 0;
+}
+
+static int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
+return 0;
+}
+
+static int arch_setup_bootlate(struct xc_dom_image *dom)
{
start_info_t *si =
xc_dom_pfn_to_ptr(dom, dom-start_info_pfn, 1);
@@ -355,19 +351,19 @@ static int arch_setup_late(struct xc_dom
#else
-static int arch_setup_early(struct xc_dom_image *dom)
-{
-xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
-return 0;
-}
-
-static int arch_setup_middle(struct xc_dom_image *dom)
-{
-xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
-return 0;
-}
-
-static int arch_setup_late(struct xc_dom_image *dom)
+static int arch_setup_meminit(struct xc_dom_image *dom)
+{
+xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
+return 0;
+}
+
+static int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
+return 0;
+}
+
+static int arch_setup_bootlate(struct xc_dom_image *dom)
{
xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
return 0;
@@ -423,7 +419,7 @@ int xc_dom_boot_mem_init(struct xc_dom_i
xc_dom_printf(%s: called\n, __FUNCTION__);
-if (0 != (rc = arch_setup_early(dom)))
+if (0 != (rc = arch_setup_meminit(dom)))
return rc;
/* allocate guest memory */
@@ -438,9 +434,6 @@ int xc_dom_boot_mem_init(struct xc_dom_i
return rc;
}
-if (0 != (rc = arch_setup_middle(dom)))
-return rc;
-
return 0;
}
@@ -497,6 +490,10 @@ int xc_dom_boot_image(struct xc_dom_imag
Re: [Xen-ia64-devel] [Patch][RFC] buildconfigs of supportingSPARSEMEM
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.
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;
}
--
yamahata
___
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
Re: [Xen-ia64-devel] XenU will crash Xen in CSet # 13773.
On Thu, Feb 01, 2007 at 05:48:33PM +0800, You, Yongkang wrote: In latest Changeset 13773, if creating XenU, Xen0 would crash and hang. The hang happened when XenU try to bring up its network. At least domU network works for me. Looking the panic log, the issue looks similar which I was seeing before c/s 13773:ef646312685f. Given that c/s 13773 resoved my issue, could you make sure your build environment? - linux-2.6.18-xen/drivers/xen/core/skbuff.c must not exist. - the following three configs shouldn't exist in linux dot config CONFIG_HAVE_ARCH_ALLOC_SKB=y CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y CONFIG_XEN_SKBUFF=y Alghough you might have checked those already or you might have built from scratch, please check it again. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH][RFC] embed memory map in domain pseudo physical address space
Hi all.
Xen/IA64 XEN_DOMCTL_arch_setup hypercall needs flexibilty
to address the following issues.
- xm dump-core. (save/restore would use in near future)
Now I'm trying to enhance xm dump-core for IA64.
Such utilities need to know the area where memory is populated.
Currently domU populates memory dense, but this wouldn't be
true in future.
Especially VTi domain builder populate memory spasely so that
xm dump-core doesn't work for domVTi.
- sparse populated domU for driver domain or other purose(e.g. NUMA)
The domain builder needs flexibility to populate memory sparsely.
This patch
- creates memory map as efi runtime data in domain pseudo
physical space,
- adds new member, memmap_info_pfn, to struct arch_shared_info
- set memmap_info_pfn to point memory map
- modifies XEN_DOMCTL_arch_setup so that it create EFI memory descriptor
following the specified memory map.
It abuses xen_ia64_boot_param to pass memory map.
NOTE: This patch depends the patches which I posted xen-devel,
but not commited yet.
thnaks.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1170334448 -32400
# Node ID 0c8f4e87a6a6e099aeb601d637be2144a00613e8
# Parent 9cb3579daa5ce32764e96698a51f2b8e95005ef1
introduce memmap_info_t
PATCHNAME: introduce_memmap_info_t
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 9cb3579daa5c -r 0c8f4e87a6a6 tools/libxc/xc_dom_boot.c
--- a/tools/libxc/xc_dom_boot.c Thu Feb 01 21:34:45 2007 +0900
+++ b/tools/libxc/xc_dom_boot.c Thu Feb 01 21:54:08 2007 +0900
@@ -263,9 +263,64 @@ static int arch_setup_bootlate(struct xc
#elif defined(__ia64__)
+#include xc_efi.h
+
static int arch_setup_meminit(struct xc_dom_image *dom)
{
xc_dom_printf(%s: doing nothing\n, __FUNCTION__);
+return 0;
+}
+
+static int ia64_setup_memmap(struct xc_dom_image *dom)
+{
+unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
+unsigned long memmap_info_pfn;
+xen_ia64_memmap_info_t* memmap_info;
+unsigned int num_mds;
+efi_memory_desc_t *md;
+
+char* start_info;
+struct xen_ia64_boot_param* bp;
+
+/* setup memmap page */
+memmap_info_pfn = dom-start_info_pfn - 1;
+xc_dom_printf(%s: memmap: mfn 0x% PRIpfn \n,
+ __FUNCTION__, memmap_info_pfn);
+memmap_info = xc_map_foreign_range(dom-guest_xc, dom-guest_domid,
+ page_size,
+ PROT_READ | PROT_WRITE,
+ memmap_info_pfn);
+if (NULL == memmap_info)
+return -1;
+/* [0, total_pages) */
+memmap_info-efi_memdesc_size = sizeof(md[0]);
+memmap_info-efi_memdesc_version = EFI_MEMORY_DESCRIPTOR_VERSION;
+num_mds = 0;
+md = (efi_memory_desc_t*)memmap_info-memdesc;
+md[num_mds].type = EFI_CONVENTIONAL_MEMORY;
+md[num_mds].pad = 0;
+md[num_mds].phys_addr = 0;
+md[num_mds].virt_addr = 0;
+md[num_mds].num_pages = dom-total_pages (PAGE_SHIFT - EFI_PAGE_SHIFT);
+md[num_mds].attribute = EFI_MEMORY_WB;
+num_mds++;
+memmap_info-efi_memmap_size = num_mds * sizeof(md[0]);
+munmap(memmap_info, page_size);
+
+/* kludge: we need to pass memmap_info page's pfn somehow.
+ * we use xen_ia64_boot_param::efi_memmap for this purpose */
+start_info = xc_map_foreign_range(dom-guest_xc, dom-guest_domid,
+ page_size,
+ PROT_READ | PROT_WRITE,
+ dom-start_info_pfn);
+if (NULL == start_info)
+return -1;
+bp = (struct xen_ia64_boot_param*)(start_info + sizeof(start_info_t));
+memset(bp, 0, sizeof(*bp));
+bp-efi_memmap = memmap_info_pfn;
+/* 4 = memmap info page, start info page, xenstore page and console page */
+bp-efi_memmap_size = 4 * PAGE_SIZE;
+munmap(start_info, page_size);
return 0;
}
@@ -274,6 +329,10 @@ static int arch_setup_bootearly(struct x
DECLARE_DOMCTL;
int rc;
+rc = ia64_setup_memmap(dom);
+if (rc)
+return rc;
+
xc_dom_printf(%s: setup firmware\n, __FUNCTION__);
memset(domctl, 0, sizeof(domctl));
@@ -283,8 +342,7 @@ static int arch_setup_bootearly(struct x
domctl.u.arch_setup.bp = (dom-start_info_pfn PAGE_SHIFT)
+ sizeof(start_info_t);
-/* 3 = start info page, xenstore page and console page */
-domctl.u.arch_setup.maxmem = (dom-total_pages - 3) PAGE_SHIFT;
+domctl.u.arch_setup.maxmem = dom-total_pages PAGE_SHIFT;
rc = do_domctl(dom-guest_xc, domctl);
return rc;
}
diff -r 9cb3579daa5c -r 0c8f4e87a6a6 tools/libxc/xc_dom_ia64.c
--- a/tools/libxc/xc_dom_ia64.c Thu Feb 01 21:34:45 2007 +0900
+++ b/tools/libxc/xc_dom_ia64.c Thu Feb 01 21:54:08 2007 +0900
@@ -76,6 +76,7 @@ static int shared_info_ia64(struct xc_do
for (i = 0; i MAX_VIRT_CPUS; i++)
shared_info-vcpu_info[i].evtchn_upcall_mask = 1;
shared_info-arch.start_info_pfn = dom-start_info_pfn;
+shared_info-arch.memmap_info_pfn = dom-start_info_pfn - 1;
return 0;
}
diff -r 9cb3579daa5c -r
Re: [Xen-ia64-devel] XenU will crash Xen in CSet # 13773.
Isaku Yamahata wrote: On Thu, Feb 01, 2007 at 05:48:33PM +0800, You, Yongkang wrote: In latest Changeset 13773, if creating XenU, Xen0 would crash and hang. The hang happened when XenU try to bring up its network. At least domU network works for me. Looking the panic log, the issue looks similar which I was seeing before c/s 13773:ef646312685f. Given that c/s 13773 resoved my issue, could you make sure your build environment? - linux-2.6.18-xen/drivers/xen/core/skbuff.c must not exist. - the following three configs shouldn't exist in linux dot config CONFIG_HAVE_ARCH_ALLOC_SKB=y CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y CONFIG_XEN_SKBUFF=y Alghough you might have checked those already or you might have built from scratch, please check it again. Hi Isaku, Our every build comes from clean hg co. I have double checked the source as you suggested. I didn't find skbuff.c and can not grep any SKB in buildconfigs/* Any other clue could I provide to track the issue? Best Regards, Yongkang ___ 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] Optimize hypercall path in VTI domain
On Wed, 2007-01-31 at 17:39 +0800, Xu, Anthony wrote: Optimize hypercall path in VTI domain, 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] [Patch] fix compile warning of xenentry.S
On Thu, 2007-02-01 at 18:07 +0900, Akio Takebe wrote: Hi, This patch fix the following compile warnig with srlz.d. 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] [PATCH][RFC] embed memory map in domain pseudo physical address space
Hi Isaku,
A few comments inline. Thanks,
Alex
On Thu, 2007-02-01 at 22:15 +0900, Isaku Yamahata wrote:
+static void
+setup_dom0_memmap_info(struct domain *d, struct fw_tables *tables,
+ int *num_mds)
+{
+ int i;
+ efi_memory_desc_t *md;
+ efi_memory_desc_t *last_mem_md = NULL;
+ xen_ia64_memmap_info_t* memmap_info;
+ unsigned long paddr_start;
+ unsigned long paddr_end;
+
+ for (i = 0; i *num_mds; i++) {
+ md = tables-efi_memmap[i];
+ if (md-attribute == EFI_MEMORY_WB
+ md-type == EFI_CONVENTIONAL_MEMORY
+ md-num_pages (1UL (PAGE_SHIFT -
EFI_PAGE_SHIFT)))
+ last_mem_md = md;
+ }
+ if (last_mem_md == NULL) {
+ printk(%s: warning:
+ no dom0 contiguous memory to hold memory map
\n,
+ __func__);
+ return;
+ }
Looks like you could search the array starting from the end as a
minor optimization.
+ paddr_end = last_mem_md-phys_addr +
+ (last_mem_md-num_pages EFI_PAGE_SHIFT);
+ paddr_start = paddr_end - (1UL (PAGE_SHIFT -
EFI_PAGE_SHIFT));
This doesn't look right. We're not multiplying by the EFI page size.
+ paddr_start = PAGE_MASK;
Seems like it's possible this mask could make (paddr_start
last_mem_md-phys_addr)
--
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 pal halt of para domain
Hi Akio,
Sorry, I should have responded to your last email on this topic. I
still have issues with this approach. Comments below.
On Fri, 2007-02-02 at 01:28 +0900, Akio Takebe wrote:
diff -r ef646312685f linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Wed Jan 31
10:59:56 2007 -0700
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Fri Feb 02
01:44:36 2007 +0900
@@ -63,6 +63,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,18 @@ static struct notifier_block xen_panic_b
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 */
+};
+
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.
#endif
extern void ia64_setup_printk_clock(void);
@@ -456,6 +469,7 @@ setup_arch (char **cmdline_p)
/* Register a call for panic conditions. */
atomic_notifier_chain_register(panic_notifier_list,
xen_panic_block);
+ register_die_notifier(xen_poweroff_block);
}
#endif
diff -r ef646312685f xen/arch/ia64/xen/fw_emul.c
--- a/xen/arch/ia64/xen/fw_emul.c Wed Jan 31 10:59:56 2007 -0700
+++ b/xen/arch/ia64/xen/fw_emul.c Fri Feb 02 01:44:36 2007 +0900
@@ -385,6 +385,8 @@ xen_pal_emulator(unsigned long index, u6
unsigned long r10 = 0;
unsigned long r11 = 0;
long status = PAL_STATUS_UNIMPLEMENTED;
+ struct vcpu *v;
+ volatile unsigned long nr_online_vcpus;
if (running_on_sim)
return pal_emulator_static(index);
@@ -606,8 +608,24 @@ xen_pal_emulator(unsigned long index, u6
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);
+
+ LOCK_BIGLOCK(current-domain);
+ nr_online_vcpus = 0;
+ for_each_vcpu( current-domain, v ){
+ if ( !test_bit(_VCPUF_down,
v-vcpu_flags) ){
+ nr_online_vcpus ++;
+ }
+ }
+ UNLOCK_BIGLOCK(current-domain);
+
+ if ( nr_online_vcpus == 0 ){
+ domain_shutdown(current-domain,
SHUTDOWN_poweroff);
+ }
+ status = PAL_STATUS_SUCCESS;
+ }
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,
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 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
On Fri, 2007-02-02 at 01:19 +0900, Akio Takebe wrote: 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 Hi Akio, 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 -- 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] [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] XenU will crash Xen in CSet # 13773. -- wrong testing.
Hi Isaku and all, I make a mistake. There is a hard-code in building script, while Xen Source has changed base kernel to 2.6.18. So build system didn't copy the right Xen0 kernel to target. Then testing met the problem. Sorry for that. We will redo the testing and send out the testing report later. Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yongkang You Sent: 2007年2月1日 22:52 To: Isaku Yamahata Cc: xen-ia64-devel Subject: Re: [Xen-ia64-devel] XenU will crash Xen in CSet # 13773. Isaku Yamahata wrote: On Thu, Feb 01, 2007 at 05:48:33PM +0800, You, Yongkang wrote: In latest Changeset 13773, if creating XenU, Xen0 would crash and hang. The hang happened when XenU try to bring up its network. At least domU network works for me. Looking the panic log, the issue looks similar which I was seeing before c/s 13773:ef646312685f. Given that c/s 13773 resoved my issue, could you make sure your build environment? - linux-2.6.18-xen/drivers/xen/core/skbuff.c must not exist. - the following three configs shouldn't exist in linux dot config CONFIG_HAVE_ARCH_ALLOC_SKB=y CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y CONFIG_XEN_SKBUFF=y Alghough you might have checked those already or you might have built from scratch, please check it again. Hi Isaku, Our every build comes from clean hg co. I have double checked the source as you suggested. I didn't find skbuff.c and can not grep any SKB in buildconfigs/* Any other clue could I provide to track the issue? Best Regards, Yongkang ___ 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] XenU will crash Xen in CSet # 13773.
On Thu, Feb 01, 2007 at 10:51:59PM +0800, Yongkang You wrote: Isaku Yamahata wrote: On Thu, Feb 01, 2007 at 05:48:33PM +0800, You, Yongkang wrote: In latest Changeset 13773, if creating XenU, Xen0 would crash and hang. The hang happened when XenU try to bring up its network. At least domU network works for me. Looking the panic log, the issue looks similar which I was seeing before c/s 13773:ef646312685f. Given that c/s 13773 resoved my issue, could you make sure your build environment? - linux-2.6.18-xen/drivers/xen/core/skbuff.c must not exist. - the following three configs shouldn't exist in linux dot config CONFIG_HAVE_ARCH_ALLOC_SKB=y CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y CONFIG_XEN_SKBUFF=y Alghough you might have checked those already or you might have built from scratch, please check it again. Hi Isaku, Our every build comes from clean hg co. I have double checked the source as you suggested. I didn't find skbuff.c and can not grep any SKB in buildconfigs/* Any other clue could I provide to track the issue? From panic log. Bringing up interface eth0: Bad page state in process 'swapper' page:e1547c60 flags:0x0010 mapping:a00100c25f50 mapcount:0 count:0 Trying to fix it up, but a reboot is needed It doesn't seems that arch_free_page() is defined as expected. - Could you check linux symbol file? 0xa00100c25f50 = netif_page_release()? If yes(I guess so), page status is correct. If not, this issue is nasty - Could you check linux-2.6.18-xen/mm/page_alloc.c compilation? Please check its cpp result and free_host_cold_page() It should include include/asm-ia64/page.h and HAVE_ARCH_FREE_PAGE should be defined so that the used arch_free_page definition should be same as in include/asm-ia64/page.h. static void fastcall free_hot_cold_page(struct page *page, int cold) ... if (arch_free_page(page, 0)) this line return; thanks. -- yamahata ___ 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
On Fri, 2007-02-02 at 11:11 +0900, Akio Takebe wrote: Hi, Alex Hmm, I'm sorry. I can boot dom0, domU with my patches on PRIMEQUEST. I'll check this issue. Thanks Akio. Note that the dump below is actually from dom0 while domU is booting. The cciss driver is for an HP hardware raid card. The domU is a 4-way, 4GB domain. dom0 is booted with dom0_max_vcpus=2 dom0_mem=16G. Disk I/O via the cciss driver seems to work normally with only dom0 running, but blows up when domU is started. Thanks, Alex 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 -- 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#13773
Xen/IA64 Healthiness Report One issues: 1. Qemu can not be opened when creating a VTI domain. But the VTI can be created successfully without qemu. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core) Service OS: RHEL4u3 IA64 SMP with 2 VCPUs VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 13773:ef646312685f Xen Schedule: credit VTI Guest Firmware Flash.fd.2006.12.01 MD5: 09a224270416036a8b4e6f8496e97854 Summary Test Report: - Total cases: 16 Passed:16 Failed: 0 Case Name Status Case Description Four_SMPVTI_Coexistpass 4 VTI (mem=256, vcpus=2) Two_UP_VTI_Co pass 2 UP_VTI (mem=256) One_UP_VTIpass1 UP_VTI (mem=256) One_UP_XenU pass1 UP_xenU(mem=256) SMPVTI_LTPpassVTI (vcpus=4, mem=512) run LTP SMPVTI_and_SMPXenU pass 1 VTI + 1 xenU (mem=256 vcpus=2) Two_SMPXenU_Coexistpass2 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_Networkpass 1 XenU (vcpus=2) and 'ping' One_SMP_XenU pass 1 SMP xenU (vcpus=2) One_SMP_VTIpass 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: - 13441:7e9077dd4010 Thanks, Zhangjingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH][RFC] embed memory map in domain pseudo physical address space
On Thu, Feb 01, 2007 at 10:15:21PM +0900, Isaku Yamahata wrote: Hi all. Xen/IA64 XEN_DOMCTL_arch_setup hypercall needs flexibilty to address the following issues. - xm dump-core. (save/restore would use in near future) Now I'm trying to enhance xm dump-core for IA64. Such utilities need to know the area where memory is populated. Currently domU populates memory dense, but this wouldn't be true in future. Especially VTi domain builder populate memory spasely so that xm dump-core doesn't work for domVTi. - sparse populated domU for driver domain or other purose(e.g. NUMA) The domain builder needs flexibility to populate memory sparsely. Hi, I agree with the goal. Although I don't have all the details in memory, why not fully build the domain (ie building pal/sal stubs) from libxc ? If this is doable, I think it should be cleaner. [This is just an idea to be discussed. If we agree this is cleaner and doable then someone might implement it. The only drawback might be code duplication] Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel][PATCH]A small optimization on flushtlb.
A small optimization on flushtlb, Replace ia64_cmpxchg with ia64_fetch_and_add. - Anthony tlbflush.patch Description: tlbflush.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] bug fix new_tlbflush_clock_period()
Hi,
__vhpt_flush() might be called from new_tlbflush_clock_period()
even if the vcpu doesn't have the per-vcpu-vhpt.
It erases 64KB memory content that starts from machine address 0.
Thanks,
Kouya
Signed-off-by: Kouya Shimura [EMAIL PROTECTED]
diff -r 0df9dc2f1d03 xen/arch/ia64/xen/flushtlb.c
--- a/xen/arch/ia64/xen/flushtlb.c Thu Feb 01 13:54:26 2007 -0700
+++ b/xen/arch/ia64/xen/flushtlb.c Fri Feb 02 14:29:45 2007 +0900
@@ -88,6 +88,9 @@ new_tlbflush_clock_period(void)
smp_mb();
for_each_domain(d) {
for_each_vcpu(d, v) {
+if (!test_bit(_VCPUF_initialised, v-vcpu_flags) ||
+VMX_DOMAIN(v))
+continue;
if (HAS_PERVCPU_VHPT(v-domain))
vcpu_vhpt_flush(v);
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]A small optimization on flushtlb.
On Fri, Feb 02, 2007 at 02:35:14PM +0800, Xu, Anthony wrote: A small optimization on flushtlb, Replace ia64_cmpxchg with ia64_fetch_and_add. Hi Anthony. This patch modifies its semantics. When tlbflush_clock is 0, it must return 0 without increment. I.e. tlbflush_clock == 0 means the overflow is detected and new_tlbflush_clock_period() may be flushing concurrently. So tlbflush_clock must not be incremented until the completion of new_tlbflush_clock_period() -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
