[Xen-ia64-devel] RE: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
From: Keir Fraser [mailto:[EMAIL PROTECTED] Sent: 2006年3月2日 16:26 On 2 Mar 2006, at 05:43, Tian, Kevin wrote: However the interesting thing is, following Cset is only for changing way to map dom0's store page, instead of domU. DomU's store page is still mapped by foreign page map. If above hint is real cause, xend start can fail earlier due to incorrect mapping when introducing dom0 into xenstore. However you all observe the bug bothering only when domU is booting... The dom0 connection is only used in anger when first creating a domU, to set up device backend state. Until that time it could be screwed and you probably would not notice. -- Keir Thanks. Make sense. -Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] [RFC] domU destroy page ref counter [0/2]
Hi all, These patches support domU destroy and Page reference counter. We reversed the cset:8790 patch, and tested these. As a result, there was no problem. Please review these patches, and give us comment. # We don't test VT-i domain. [1/2] : domU destroy [2/2] : Page reference counter Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan, and Fujitsu team ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] SEDF scheduler
hi, I have just tried the SEDF scheduler. It doesn't seem as broken as several monthes ago. Did anyone tried SEDF recently ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] SEDF scheduler
Hi Tristan, Fujitsu team is testing Xen with the SEDF scheduler. However, the SEDF scheduler has bugs. Fujitsu team is trying a bug-fix. Best regards, Kan, and Fujitsu team Tristan Gingold wrote: hi, I have just tried the SEDF scheduler. It doesn't seem as broken as several monthes ago. Did anyone tried SEDF recently ? 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] SEDF scheduler
Le Jeudi 02 Mars 2006 15:47, Masaki Kanno a écrit : Hi Trisran, The SEDF scheduler bugs are only xen/ia64. To be precise, the SEDF scheduler source codes does not include bugs. Because there are not the following functions, action of the SEDF scheduler becomes inaccuracy. Ok, thank you for the details. Tristan. ___ 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
Hi, Kevin
Thank you for your advice.
I tried to compile define ARCH_HAS_DEV_MEM.
but nothing changed.
Best Regards,
Akio Takebe
Hi, Akio,
Currently linux-2.6-xen-sparse/driver/xen/char/ is not included
in compilation for xen/ia64, so you're still using linux-style kmem
path.
Try to compile that directory into your xenlinux image, and
define ARCH_HAS_DEV_MEM, and then see anything changed
for you.
However the interesting thing is, following Cset is only for
changing way to map dom0's store page, instead of domU. DomU's
store page is still mapped by foreign page map. If above hint is real
cause, xend start can fail earlier due to incorrect mapping when
introducing dom0 into xenstore. However you all observe the bug
bothering only when domU is booting...
Thanks,
Kevin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Akio Takebe
Sent: 2006年3月2日 8:44
To: Xu, Anthony; Magenheimer, Dan (HP Labs Fort Collins); xen-devel
Cc: yo.fujita; Akio Takebe; xen-ia64-devel@lists.xensource.com
Subject: RE: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
Hi, Anthony
Thank you for your advice.
I checked retun value of mmap(), and it is not NULL.
I'll check vcpu_translate().
Best Regards,
Akio Takebe
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ト・ヤツ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).
RE: [Xen-ia64-devel] [PATCH] XEN: accelerate guest tr search.
I have a couple of concerns with this patch: 1) Because of vcpu_quick_region_check() this patch will matter (on Linux) only for code/data in region 7 that is not pinned by a guest TR. Vcpu_quick_region_check() avoids checking the guest TRs if accessing a region that has no TRs set (e.g. on Linux, the vast majority of misses will never check any of the guest TRs). 2) The code assumes that a guest utilizes the TRs in order with no holes (e.g. TR0-3 rather than TR0,2,4,6). This is true for Linux but if we are going to add this performance shortcut, it might as well be more robust. 3) I think we should be very careful about making changes that are intended to improve performance without doing any benchmarking. Many times I have seen code that was intended to improve performance actually -- surprise! -- result in performance degradation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Xu, Anthony Sent: Thursday, March 02, 2006 6:10 AM To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH] XEN: accelerate guest tr search. Guest has 8 I/D TR entries, when tlb miss happens, VMM will check these 8 TR entries to see whether corresponding tlb entry can be found. In fact, guest may not use all of these 8 entry, for example, linux only uses first 2 ITR and first 4 DTR(maybe not exact). I add two members in vcpu struct, itr_maxslot, dtr_maxslot to record max entry number of guest ITR and DTR which are used by guest. So when VMM searches guest TRs, it doesn't need to check all TRs, just those used by guest. Since searching guest TR is a frequent operation, this patch should improve performance of dom0 and domU in theory. I don't have data :-). Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, -Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: Missing ia64 files in xen-unstable
On 2 Mar 2006, at 18:08, Magenheimer, Dan (HP Labs Fort Collins) wrote: are missing in xen-unstable.hg though they exist in xen-ia64-unstable.hg. I'm not sure how this could have happened but it has broken the Xen/ia64 build (in xen-unstable.hg). Keir, could you hg add them (as empty files) please? Fixed. I think my local repository got confused when I merged in the ia64 tree. It believed it was tracking those files, and they were present in the tree, but somehow that didn't get pushed up to the parent. I blew it away. :-) -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] RE: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
On Thu, 2006-03-02 at 18:41 +, Ewan Mellor wrote: These are requests from the xenbus driver to create watches to monitor for new devices being created. That presumably means that either your xenbus driver is fubar'd, or the mmap'd page is bust, as discussed earlier. The requests that you are seeing are from xenconsoled and xend, each of which is using the unix domain socket to talk to the store, not the shared page. If I dump the xsd_kva page using mmap from another app, there are a few entries made: : 01 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 0010: 64 65 76 69 63 65 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 0400: 10 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 0410: 45 4e 4f 45 4e 54 00 00 00 00 00 00 00 00 00 00 0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 0800: 17 00 00 00 17 00 00 00 00 00 00 00 17 00 00 00 As you indicate, lots of output in the xenstored-trace file, but hardly anything here. We are getting some transactions in there though, so maybe we're dealing with a memory ordering issue. 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] [PATCH] XEN: accelerate guest tr search.
From: Magenheimer, Dan (HP Labs Fort Collins) Sent: 2006年3月3日 1:52 I have a couple of concerns with this patch: 1) Because of vcpu_quick_region_check() this patch will matter (on Linux) only for code/data in region 7 that is not pinned by a guest TR. Vcpu_quick_region_check() avoids checking the guest TRs if accessing a region that has no TRs set (e.g. on Linux, the vast majority of misses will never check any of the guest TRs). Agree, vcpu_quick_region_check is a good approach, I'll introduce it into vti-domain, yes, it can filter majority of tlb misses. 2) The code assumes that a guest utilizes the TRs in order with no holes (e.g. TR0-3 rather than TR0,2,4,6). This is true for Linux but if we are going to add this performance shortcut, it might as well be more robust. Agree, this patch seems to be linux-specifical, Maybe bitmap is a better approach, which is OS-independent. 3) I think we should be very careful about making changes that are intended to improve performance without doing any benchmarking. Many times I have seen code that was intended to improve performance actually -- surprise! -- result in performance degradation. Agree, but it's unpractical to let developer to do benchmark testing, Since Fujitsu will deliver regular performance reports, I think we could depend on these reports to find out the patch which cause performance degradation. Thanks, Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] XEN: accelerate guest tr search.
Xu, Anthony wrote: 3) I think we should be very careful about making changes that are intended to improve performance without doing any benchmarking. Many times I have seen code that was intended to improve performance actually -- surprise! -- result in performance degradation. Agree, but it's unpractical to let developer to do benchmark testing, Since Fujitsu will deliver regular performance reports, I think we could depend on these reports to find out the patch which cause performance degradation. The correct approach is to get all the necessary features in, and then do the system-wide benchmark and fine-tuning, rather than local tweak or small benchmarks for large scaled system like Itanium -Fred ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] [RFC] Remove mmzone.h and warning: MAX_ORDER redefined
Hi, This patch removed xen/include/asm-ia64/linux/mmzohe.h which is not used now, and removed warning MAX_ORDER redefined from xen/common/page_alloc.c. However, mmzohe.h may be necessary when we support virtual memmap. I hope that we create new header files specific to xen/ia64 if necessary then. Please give me comment. Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan remove.mmzone.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] [RFC] Remove mmzone.h and warning:MAX_ORDER redefined
Good work, Kan. It's cleaner to remove unused files though it's possibly used in the future. As you said, we can pull it back if necessary, and it's very likely original files will be modified more or less to accommodate XEN specific requirement even copying that time. Thanks, Kevin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Masaki Kanno Sent: 2006年3月3日 13:27 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH] [RFC] Remove mmzone.h and warning:MAX_ORDER redefined Hi, This patch removed xen/include/asm-ia64/linux/mmzohe.h which is not used now, and removed warning MAX_ORDER redefined from xen/common/page_alloc.c. However, mmzohe.h may be necessary when we support virtual memmap. I hope that we create new header files specific to xen/ia64 if necessary then. Please give me comment. Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
