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-devel

RE: [Xen-devel] xen_phys_start for 32b

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] xen_phys_start for 32b
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Wed, 7 Jan 2009 13:37:31 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Wed, 07 Jan 2009 13:38:37 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C58A7D74.20D26%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4F65016F6CB04E49BFFA15D4F7B798D92D483E58@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C58A7D74.20D26%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclvyQrixVQbl8uESyOiS/TNP5uIqAAEbUEWABRCWuAACAQwRQAADgnwABZdSx8ADRKycAABHZ3+AAufG4A=
Thread-topic: [Xen-devel] xen_phys_start for 32b
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Wednesday, January 07, 2009 7:41 AM
>
> On 07/01/2009 15:13, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote:
>
> >>> But shouldn't [xenheap_phys_start, xenheap_phys_end] represent all of the
> >>> memory that the hypervisor "owns" and which must be protected from even
> >>> privileged domain writes (modulo the real mode/trampoline code, which has
> >>> its
> >>> own variables that represent its range)?  While it may be "OK" on 32b
> >>> systems,
> >>> it is not "logically correct" and does not match 64b systems (where this 
> >>> low
> >>> memory is not so protected).  Would it break anything to set
> >>> xenheap_phys_start to __pa(&_start) for 32b builds?
> >>
> >> So what issue does this fix for you?
> >
> > It moves the '#ifdef __x86_64__' in a couple of places in an upcoming patch
> > into just setup.c ;-)  So practically speaking, it is not very important.  
> > But
> > it seems like it would just be cleaner, today, to have this variable (and
> > xen_phys_start?) be consistent across builds; and thus, usable with the
> > intended meaning in the future.
>
> Xenheap will disappear entirely on x86/64 in future. So long term is that
> i386 and x86/64 are actually to diverge significantly in this area.
>
> Of course I'll consider any patch on its own merits of usefulness and
> cleanliness.

OK, here is a very small and simple patch to "fix" this.  Note that I used a 
new '#idef' instead of '#else' to the previous because this statement is 
logically distinct from the previous block and there is no difference in the 
generated code.

----------------

For IA32 builds, set xen_phys_start (and by extension, xenheap_phys_start) to 
be the physical address of the start of xen (instead of the previous value, 0).

Signed-off-by: Joseph Cihula <joseph.cihula@xxxxxxxxx>

diff -r e2f36d066b7b xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c      Mon Dec 22 13:48:40 2008 +0000
+++ b/xen/arch/x86/setup.c      Wed Jan 07 09:19:58 2009 -0800
@@ -868,6 +868,9 @@ void __init __start_xen(unsigned long mb
     nr_pages += (__pa(&_start) - xen_phys_start) >> PAGE_SHIFT;
     vesa_init();
 #endif
+#ifndef __x86_64__
+    xen_phys_start = __pa(&_start);
+#endif
     xenheap_phys_start = xen_phys_start;
     printk("Xen heap: %luMB (%lukB)\n",
            nr_pages >> (20 - PAGE_SHIFT),


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