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 07:13:09 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Wed, 07 Jan 2009 07:13:38 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C58A1E3C.20CDA%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: <4F65016F6CB04E49BFFA15D4F7B798D92D3E8263@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C58A1E3C.20CDA%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclvyQrixVQbl8uESyOiS/TNP5uIqAAEbUEWABRCWuAACAQwRQAADgnwABZdSx8ADRKycA==
Thread-topic: [Xen-devel] xen_phys_start for 32b
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Wednesday, January 07, 2009 12:54 AM
>
> On 06/01/2009 22:19, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote:
>
> >> It's not used for domheap either. In fact it's not really used at all. 
> >> Hence
> >> encompassing it within xenheap_phys_start to xenheap_phys_end works okay.
> >>
> >
> > 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.

Joe

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