This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-ia64-devel] Community effort neededtocatch upwithxen-unstable

To: "John Byrne" <john.l.byrne@xxxxxx>
Subject: RE: [Xen-ia64-devel] Community effort neededtocatch upwithxen-unstable
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 2 Sep 2005 10:50:14 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 02 Sep 2005 02:48:13 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWvZqLq66NFDvT0SxG0t4WzIxQpTQAANxPQ
Thread-topic: [Xen-ia64-devel] Community effort neededtocatch upwithxen-unstable
>From: John Byrne [mailto:john.l.byrne@xxxxxx]
>I think the problem is that your latest patch plops the store page in
>the middle of kernel memory and nothing prevents the kernel from using
>it. In x86, this is handled by allocating the xenstore and console
>immediately after the kernel and then setting the pt_base parameter so
>that they are never used. I'm not sure about this, but I don't see
>anything keeping from using it.
>I'm off for the night.

So you're talking problem from when booting domU? You're right about the
x86 behavior, but that's different on current ia64 model. Dan prefers to
adopt a transparent virtualization mechanism, so minimal changes are
required to touch common linux code. If we also place those system pages
after the kernel image, you have to modify efi syb-system to ignore
these pages.

Currently I just put the last page allocated to xenU as the store page,
not in the middle. But yes, there's still one problem in dom_fw_init,
where all allocated pages are exposed to domain. Instead we should
reserve the last page and let store page out of domain's scope. Check
whether following changes solves your issue:

diff -r 8799d14bef77 xen/arch/ia64/dom_fw.c
--- a/xen/arch/ia64/dom_fw.c    Thu Aug 25 22:53:20 2005
+++ b/xen/arch/ia64/dom_fw.c    Fri Sep  2 10:38:11 2005
@@ -512,6 +512,11 @@
                return 0;
+       /* Last page is for xenstore, and not exported to domain */
+       if (d != dom0)
+               maxmem = (d->max_pages - 1) * PAGE_SIZE;
        memset(fw_mem, 0, fw_mem_size);

 #ifdef XEN


Xen-ia64-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>