WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

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

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-ia64-devel] Community effort neededtocatch upwithxen-unstable
From: John Byrne <john.l.byrne@xxxxxx>
Date: Fri, 02 Sep 2005 11:17:09 -0700
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 02 Sep 2005 18:14:58 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD807C33166@pdsmsx403>
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>
References: <571ACEFD467F7749BC50E0A98C17CDD807C33166@pdsmsx403>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050716)

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

Thanks,
Kevin


With all the various patches, things work fine and I get a login prompt.

I knew the x86 model was different, what I didn't know was what you did with this patch was legal. It looks to me as if you have the operating system accessing a page the VM really shouldn't let it have. I was trying to figure out how to reserve the page in the EFI memory map: add it to the end of the hypercall page or something. Maybe its fortunate I had to go home so you could come up with the more straightforward fix.

Spoke a little too soon, again. Looks like dom0 just crashed hard:

(XEN) +01+01Heartbeat... iip=f0000000040092d0,psr.i=0,pend=1
(XEN) +01ia64_fault: General Exception: IA-64 Reserved Register/Field fault (data access): reflecting

I've no clue what the problem might be, things were idle. Still, things are better.

Thanks,

John




_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

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