[Xen-ia64-devel] [PATCH]: remove xen_timer_interval
Hi,
xen_timer_interval is not used. Removed.
tests: compile + dom0 boot.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID ac1ee42ff99c04a3a7d37783b54263f6f84abf1b
# Parent c3f82be17d98100123bb8b5f62306820cdd3d6f2
xen_timer_interval removed (was not used).
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r c3f82be17d98 -r ac1ee42ff99c xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c Tue Feb 28 04:50:44 2006
+++ b/xen/arch/ia64/xen/vcpu.c Tue Feb 28 05:29:40 2006
@@ -976,15 +976,6 @@
return (IA64_NO_FAULT);
}
-// parameter is a time interval specified in cycles
-void vcpu_enable_timer(VCPU *vcpu,UINT64 cycles)
-{
-PSCBX(vcpu,xen_timer_interval) = cycles;
-vcpu_set_next_timer(vcpu);
-printf(vcpu_enable_timer(%d): interval set to %d cycles\n,
- PSCBX(vcpu,xen_timer_interval));
-}
-
IA64FAULT vcpu_set_itv(VCPU *vcpu, UINT64 val)
{
extern unsigned long privop_trace;
@@ -992,10 +983,11 @@
if (val 0xef00) return (IA64_ILLOP_FAULT);
PSCB(vcpu,itv) = val;
if (val 0x1) {
-printf( vcpu_set_itv(%d): vitm=%lx, setting to 0\n,val,PSCBX(vcpu,domain_itm));
+ printf( vcpu_set_itv(%d): vitm=%lx, setting to 0\n,
+ val,PSCBX(vcpu,domain_itm));
PSCBX(vcpu,domain_itm) = 0;
}
- else vcpu_enable_timer(vcpu,100L);
+ else vcpu_set_next_timer(vcpu);
return (IA64_NO_FAULT);
}
@@ -1077,7 +1069,6 @@
//UINT64 s = PSCBX(vcpu,xen_itm);
UINT64 s = local_cpu_data-itm_next;
UINT64 now = ia64_get_itc();
- //UINT64 interval = PSCBX(vcpu,xen_timer_interval);
/* gloss over the wraparound problem for now... we know it exists
* but it doesn't matter right now */
diff -r c3f82be17d98 -r ac1ee42ff99c xen/include/asm-ia64/domain.h
--- a/xen/include/asm-ia64/domain.h Tue Feb 28 04:50:44 2006
+++ b/xen/include/asm-ia64/domain.h Tue Feb 28 05:29:40 2006
@@ -59,7 +59,6 @@
unsigned long domain_itm;
unsigned long domain_itm_last;
unsigned long xen_itm;
- unsigned long xen_timer_interval;
#endif
mapped_regs_t *privregs; /* save the state of vcpu */
unsigned long metaphysical_rr0; // from arch_domain (so is pinned)
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]: unused fields in mm_struct commented out.
Hi, just to clean-up mm_struct and to save a few bytes. Tests: dom0+domU boot shutdown. Tristan. # HG changeset patch # User [EMAIL PROTECTED] # Node ID 70281794bd8fa0769bd54211e6ed3227c6cdf5b5 # Parent e2aa944787e08d30aa608e1aa40cec598e39cd1b Unused fields in mm_struct commented out. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r e2aa944787e0 -r 70281794bd8f xen/include/asm-ia64/domain.h --- a/xen/include/asm-ia64/domain.h Tue Feb 28 06:07:11 2006 +++ b/xen/include/asm-ia64/domain.h Tue Feb 28 06:21:06 2006 @@ -107,6 +107,7 @@ * by mmlist_lock */ +#ifndef XEN unsigned long start_code, end_code, start_data, end_data; unsigned long start_brk, brk, start_stack; unsigned long arg_start, arg_end, env_start, env_end; @@ -116,6 +117,7 @@ unsigned long saved_auxv[40]; /* for /proc/PID/auxv */ unsigned dumpable:1; +#endif #ifdef CONFIG_HUGETLB_PAGE int used_hugetlb; #endif ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [PATCH] Clean up warning for page_alloc.c
Hi Kevin, I researched whether the declaration defined in mmzone.h is used. As a result, most of the declared definitions were needless for mmzone.h. The necessary definition was only one line of #include linux/topology.h if I invalidated some definitions of include/asm-ia64/linux-xen/linux/gfp.h. The details please see example1.diff. Request for comment. Hi all, By the way, MAX_ORDER is used in the following files. - xen/include/asm-ia64/xen/asm/meminit.h -- line 42:#define ORDERROUNDDOWN(n) ((n) ~((PAGE_SIZEMAX_ORDER)-1)) - xen/arch/ia64/xen/xenmem.c -- line 46:ASSERT(mpt_order = MAX_ORDER); I removed mmzone.h, but did not become any compilation errors. It is the reason why ORDERROUNDDOWN is not used in Xen/ia64. When I compiled Xen, I didn't use debug option. I think that a definition of MAX_ORDER should be declared in header files. Request for comment, too. Best regards, Kan Masaki Kanno wrote: Hi Kevin, I will research whether the declaration defined in mmzone.h is used. Best regards, Kan Tian, Kevin wrote: To me, it's more meaningful to change mmzone.h, because we're in xen world. Due to historical reason, still some of linux files are remained unchanged in xen/ia64, with most stuff useless (like MMZONE below). It's only work around in early stage for compilation, and now time for us to remove most of them and create new header files specific to xen/ia64 if necessary. I think this can be the guideline when you're cleaning up with confliction seen. ;-) Thanks, Kevin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Masaki Kanno Sent: 2006定2埖27晩 12:35 To: [EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] Clean up warning for page_alloc.c Hi all, I clean up warning in xen/ia64. The MAX_ORDER is redefined as I show below it. I didn't change the Linux original code mmzone.h and thought to change a local definition in page_alloc.c. This patch changes a local definition from MAX_ORDER to XEN_MAX_ORDER. page_alloc.c:222:1: warning: MAX_ORDER redefined In file included from /home/kanno/xen-ia64-unstable.hg/xen/include/asm-ia64/linux-xen/linux/gfp.h: 7, from /home/kanno/xen-ia64-unstable.hg/xen/include/asm/mm.h:6, from /home/kanno/xen-ia64-unstable.hg/xen/include/linux/mm.h:79, from /home/kanno/xen-ia64-unstable.hg/xen/include/asm-ia64/linux-xen/asm/uacc ess.h:39, from /home/kanno/xen-ia64-unstable.hg/xen/include/asm/domain.h:143, from /home/kanno/xen-ia64-unstable.hg/xen/include/xen/sched.h:15, from page_alloc.c:28: /home/kanno/xen-ia64-unstable.hg/xen/include/asm-ia64/linux/mmzone.h:19: 1: warning: this is the location of the previous definition Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan ___ Xen-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-devel example1.diff 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] Weekly benchmark results [2/3rd week]
Le Mercredi 22 Février 2006 00:55, Magenheimer, Dan (HP Labs Fort Collins) a écrit : After more investigation, this may not be related to a newer hotplug/udev. Fujita -- Have you been able to get this to work on RH4? Everyone -- Is anybody else seeing this problem? It seems to occur starting domU on RH4 (but not on Debian). The symptom is that when xm create is executed, the result is: Error: Device 769 (vbd) could not be connected. Hotplug scripts not working. Cset 8604 seems to work for me. Tip fails and cset 8717 fails. If anyone is successfully booting a domU on a clean install of tip on RH4, please respond. Maybe I am late, but I now encounter this problem with my RHEL3 (Red Hat Enterprise Linux AS release 3 (Taroon Update 5)). Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week]
On Tue, 2006-02-28 at 18:47 +0900, Akio Takebe wrote:
Hi, Dan
Thank you. I'm sorry for my delay debug.
I'm still debuging, but it is very difficult...
Much advice is welcome. :-)
The patch which I sended once was incorrect patch.
Now I can boot domU by using the following patch.
Looks like that effectively reverts the cset in question as well.
FWIW, I wrote a small C program (attached) that does exactly what this
section of code is trying to do. That much seems to work just fine on
RHEL4U2. Is the mmap() itself failing when run as part of xenstore, or
is it a difference in the resulting interface versus
xc_map_foreign_range()? Thanks,
Alex
--
Alex Williamson HP Linux Open Source Lab
#include stdio.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include string.h
#include errno.h
#include unistd.h
#include stdlib.h
#include sys/mman.h
int main(void) {
int rc, fd;
char str[20];
unsigned long kva;
void *mmkva;
fd = open(/proc/xen/xsd_kva, O_RDONLY);
if (fd == -1) {
printf(open(/proc/xen/xsd_kva) failed: %s\n, strerror(errno));
return 1;
}
rc = read(fd, str, sizeof(str));
if (rc == -1) {
printf(read() failed: %s\n, strerror(errno));
close(fd);
return 1;
}
close(fd);
str[rc] = '\0';
kva = strtoul(str, NULL, 0);
printf(kva: 0x%lx\n, kva);
fd = open(/dev/kmem, O_RDWR);
if (fd == -1) {
printf(open(/dev/kmem) failed: %s\n, strerror(errno));
return 1;
}
mmkva = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE, MAP_SHARED, fd, kva);
if (mmkva == MAP_FAILED) {
printf(mmap() failed: %s\n, strerror(errno));
close(fd);
return 1;
}
printf(success\n);
sleep(60);
munmap(mmkva, getpagesize());
close(fd);
return 0;
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Réf. : RE: [Xen-ia64-devel] SMP guest: first boot
Eddie, did you have a chance (some time) to run a quick test in SMP mode after last Tristan fix ? Jean-Paul Dong, Eddie [EMAIL PROTECTED] Envoyé par : [EMAIL PROTECTED] 28/02/2006 02:05 Pour :Alex Williamson [EMAIL PROTECTED], Tristan Gingold [EMAIL PROTECTED] cc :xen-ia64-devel@lists.xensource.com Objet :RE: [Xen-ia64-devel] SMP guest: first boot Congratulations too! Now more SMP host issues can be found, right? Bravo Tristan! thx,eddie Alex Williamson wrote: On Mon, 2006-02-27 at 14:01 +0100, Tristan Gingold wrote: Hi, this is my first dom0 boot using 2 cpus: Nice work 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] [PATCH] Cleanup hypercall.h
Seems it's similar issue as previous one (cpu_online_map). For x86, CONFIG_SMP is the base and always on, so it's very likely for common code to access variables defined only under CONFIG_SMP. Should we enable CONFIG_SMP by default, once it gets more stable? Tristan, how about your opinion? Is it time for changing that now? You're right, with CONFIG_SMP, it looks like xen-unstable will build. Given the statement from Keir that UP isn't supported on xen/i386, I'm in favor of making SMP the default config for xen/ia64. Ultimately we need to go there anyway, and with all the recent patches, SMP is pretty well function. Thanks, If there's any question of stability, perhaps we can turn on CONFIG_SMP at compile-time but turn it off (at least for now) at run-time (e.g. implement nosmp but turn it on by default for now). Dan ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH]: remove xen_timer_interval
On Tue, 2006-02-28 at 10:05 +0100, Tristan Gingold wrote: Hi, xen_timer_interval is not used. Removed. tests: compile + dom0 boot. Applied. -- 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] Re: [PATCH]: warnings and clean-up of the day.
On Tue, 2006-02-28 at 10:43 +0100, Tristan Gingold wrote: Hi, the title say all. Test: dom0 + domU booted. Applied. This had a lot of overlaps with ia64 cset 9005 in irq.c and process.c, please make sure I merged them to your satisfaction. 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] Re: [PATCH]: unused fields in mm_struct commented out.
On Tue, 2006-02-28 at 10:57 +0100, Tristan Gingold wrote: Hi, just to clean-up mm_struct and to save a few bytes. Tests: dom0+domU boot shutdown. Applied. -- 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
RE: [Xen-ia64-devel] [PATCH] VTI: updated vtlb, support_non_contiguous memory on vtidomain
On Tue, 2006-02-28 at 17:48 +0800, Xu, Anthony wrote: From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年2月25日 5:28 Couple quick comments in scanning through the non-vmx parts of this patch (which are more significant that I was expecting give the patch description): Previously VTI-domain only supported contiguous memory, this patch is intended to make VTI-domain support non-contiguous memory. I tried to apply patches in the order that they came in last night, but unfortunately that caused this one to get more rejects than I felt comfortable fixing up on the fly. Could you please update it to apply to the current tree and I'll apply it first on the next round. 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
RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week]
From: Akio Takebe [mailto:[EMAIL PROTECTED] Thank you. I'm sorry for my delay debug. I'm still debuging, but it is very difficult... Yes, it is definitely a weird bug! Much advice is welcome. :-) OK, I will post a message to xen-devel to see if any of the core Xen or distro people have ideas. The patch which I sended once was incorrect patch. Now I can boot domU by using the following patch. I can confirm that this fix works for me too. Dan ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Help? Red Hat fails, Suse/Debian both work fine
Hi all -- We are seeing a strange problem where a recent cset causes Red Hat to fail domU boot on ia64 complaining of a hotplug problem but doesn't cause any problem for Suse or Debian. It is likely some subtle difference (or bug), perhaps in mmap? Suggestions/advice from anyone more familiar with distro differences (on ia64) would be appreciated. Changeset is xen-unstable 8783 (Use /dev/kmem to map dom0 xenstore page instead of abusing the foreign mapping interface., Feb 8, committed by Christian). Backing out this changeset or using the small patch below causes the problem to go away, so we have a workaround, but a root cause would be nice to know and fix. Full thread of discussion can be found here: http://lists.xensource.com/archives/html/xen-ia64-devel/2006-02/msg00104 .html Thanks, Dan -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 28, 2006 2:47 AM To: Magenheimer, Dan (HP Labs Fort Collins); yo.fujita; xen-ia64-devel@lists.xensource.com Cc: Akio Takebe Subject: RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week] Hi, Dan I'm still debuging, but it is very difficult... Much advice is welcome. :-) Now I can boot domU by using the following patch. diff -r 6c43118bdba8 tools/xenstore/xenstored_domain.c --- a/tools/xenstore/xenstored_domain.c Fri Feb 24 15:41:08 2006 -0700 +++ b/tools/xenstore/xenstored_domain.c Tue Feb 28 18:20:16 2006 +0900 @@ -467,6 +467,7 @@ static int dom0_init(void) int rc, fd; evtchn_port_t port; unsigned long kva; + unsigned long mfn; char str[20]; struct domain *dom0; @@ -500,9 +501,16 @@ static int dom0_init(void) if (fd == -1) return -1; - dom0-interface = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE, - MAP_SHARED, fd, kva); - if (dom0-interface == MAP_FAILED) + mfn=((0x0fff kva) 14); +/* +dom0-interface = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE, + MAP_SHARED, fd, kva); +*/ + dom0-interface = xc_map_foreign_range( + *xc_handle, 0, + getpagesize(), PROT_READ|PROT_WRITE, mfn); + if (!dom0-interface) +// if (dom0-interface == MAP_FAILED) goto outfd; close(fd); Best Regards, Akio Takebe Hi Akio -- Any more progress on this issue? If you are stuck, maybe we should post the problem to xen-devel to see if we can get help from a Red Hat person (since the problem doesn't occur on Suse or Debian). Thanks, Dan -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: Thursday, February 23, 2006 8:45 PM To: Magenheimer, Dan (HP Labs Fort Collins); yo.fujita; xen-ia64-devel@lists.xensource.com Cc: Akio Takebe Subject: RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week] Hi, Dan and Alex I think this issue is only on ia64. I seem that [EMAIL PROTECTED]/char/mem.c is used on ia64, but [EMAIL PROTECTED]/xen/char/mem.c is used on x86. So I think pfn or kva aren't set correctly. We tried to boot domU with revesing cset xen-ia64-ustable.8790 and it was good work. I'm still debugging it. :- Best Regards, Akio Takebe Confirmed cset xen-unstable 8783 fails while 8782 succeeds. Perhaps there's something different about mmap on RH vs Suse and Debian? Perhaps only on ia64? ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
On 28 Feb 2006, at 21:45, Magenheimer, Dan (HP Labs Fort Collins) wrote: We are seeing a strange problem where a recent cset causes Red Hat to fail domU boot on ia64 complaining of a hotplug problem but doesn't cause any problem for Suse or Debian. It is likely some subtle difference (or bug), perhaps in mmap? Suggestions/advice from anyone more familiar with distro differences (on ia64) would be appreciated. Changeset is xen-unstable 8783 (Use /dev/kmem to map dom0 xenstore page instead of abusing the foreign mapping interface., Feb 8, committed by Christian). Backing out this changeset or using the small patch below causes the problem to go away, so we have a workaround, but a root cause would be nice to know and fix. Not very many apps use /dev/kmem, and xenstored only uses it once, to map domain0's xenbus page. Can't you just trace the hell out of it and find out exactly what MFN is mapping and why it (presumably) is different from the one allocated by the domain0 kernel for the purpose (the kernel virtual address of which is exported to xenstored via /proc)? We weren't delighted to end up using /dev/kmem for this purpose, but I don't think our use is an abuse of the interface (I think we're using /dev/kmem mmap() 'within spec' :-). -- Keir ___ 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] CONFIG_DOMAIN0_CONTIGUOUS in domain.c
Dan: I guess you misunderstand here. Definitely we need to fix this bug first for the path #undef can't work as pre-clean up patch. With this patch, everything can stay with same functionality. It is not necessary to combine it together with VP+DMA patches that makes things much complicate. Eddie -Original Message- From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:[EMAIL PROTECTED] Sent: 2006年3月1日 7:36 To: Dong, Eddie; Tian, Kevin; Isaku Yamahata Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] CONFIG_DOMAIN0_CONTIGUOUS in domain.c 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] RE: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
It is likely some subtle difference (or bug), perhaps in mmap?
As I know, in Redhat, mmap can return NULL address, but seems xen
can't handle this situation, see below code segment:
In function vcpu_translate() of vcpu.c file
else if (!region warn_region0_address) {
REGS *regs = vcpu_regs(vcpu);
unsigned long viip = PSCB(vcpu,iip);
unsigned long vipsr = PSCB(vcpu,ipsr);
unsigned long iip = regs-cr_iip;
unsigned long ipsr = regs-cr_ipsr;
printk(vcpu_translate: bad address %p, viip=%p, vipsr=%p, iip=%p,
ipsr=%p continuing\n, address, viip, vipsr, iip, ipsr);
}
warn_region0_address is turned off by default,
so maybe we can turn on warn_region0_address to see whether this is the root
cause.
Thanks,
-Anthony
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Magenheimer, Dan
(HP Labs Fort Collins)
Sent: 2006年3月1日 5:45
To: xen-devel
Cc: yo.fujita; Akio Takebe; xen-ia64-devel@lists.xensource.com
Subject: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
Hi all --
We are seeing a strange problem where a recent cset causes
Red Hat to fail domU boot on ia64 complaining of a hotplug
problem but doesn't cause any problem for Suse or Debian.
It is likely some subtle difference (or bug), perhaps in mmap?
Suggestions/advice from anyone more familiar with distro
differences (on ia64) would be appreciated.
Changeset is xen-unstable 8783 (Use /dev/kmem to map dom0
xenstore page instead of abusing the foreign mapping interface.,
Feb 8, committed by Christian). Backing out this changeset
or using the small patch below causes the problem to go away,
so we have a workaround, but a root cause would be nice
to know and fix.
Full thread of discussion can be found here:
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-02/msg00104
.html
Thanks,
Dan
-Original Message-
From: Akio Takebe [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 28, 2006 2:47 AM
To: Magenheimer, Dan (HP Labs Fort Collins); yo.fujita;
xen-ia64-devel@lists.xensource.com
Cc: Akio Takebe
Subject: RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week]
Hi, Dan
I'm still debuging, but it is very difficult...
Much advice is welcome. :-)
Now I can boot domU by using the following patch.
diff -r 6c43118bdba8 tools/xenstore/xenstored_domain.c
--- a/tools/xenstore/xenstored_domain.c Fri Feb 24 15:41:08 2006 -0700
+++ b/tools/xenstore/xenstored_domain.c Tue Feb 28 18:20:16 2006 +0900
@@ -467,6 +467,7 @@ static int dom0_init(void)
int rc, fd;
evtchn_port_t port;
unsigned long kva;
+ unsigned long mfn;
char str[20];
struct domain *dom0;
@@ -500,9 +501,16 @@ static int dom0_init(void)
if (fd == -1)
return -1;
- dom0-interface = mmap(NULL, getpagesize(),
PROT_READ|PROT_WRITE,
- MAP_SHARED, fd, kva);
- if (dom0-interface == MAP_FAILED)
+ mfn=((0x0fff kva) 14);
+/*
+dom0-interface = mmap(NULL, getpagesize(),
PROT_READ|PROT_WRITE,
+ MAP_SHARED, fd, kva);
+*/
+ dom0-interface = xc_map_foreign_range(
+ *xc_handle, 0,
+ getpagesize(), PROT_READ|PROT_WRITE, mfn);
+ if (!dom0-interface)
+// if (dom0-interface == MAP_FAILED)
goto outfd;
close(fd);
Best Regards,
Akio Takebe
Hi Akio --
Any more progress on this issue? If you are stuck,
maybe we should post the problem to xen-devel to
see if we can get help from a Red Hat person (since
the problem doesn't occur on Suse or Debian).
Thanks,
Dan
-Original Message-
From: Akio Takebe [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 23, 2006 8:45 PM
To: Magenheimer, Dan (HP Labs Fort Collins); yo.fujita;
xen-ia64-devel@lists.xensource.com
Cc: Akio Takebe
Subject: RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week]
Hi, Dan and Alex
I think this issue is only on ia64.
I seem that [EMAIL PROTECTED]/char/mem.c is used on ia64,
but [EMAIL PROTECTED]/xen/char/mem.c is used on x86.
So I think pfn or kva aren't set correctly.
We tried to boot domU with revesing cset xen-ia64-ustable.8790
and it was good work.
I'm still debugging it. :-
Best Regards,
Akio Takebe
Confirmed cset xen-unstable 8783 fails while 8782 succeeds.
Perhaps there's something different about mmap on RH
vs Suse and Debian? Perhaps only on ia64?
___
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
