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: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] xen_phys_start for 32b
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 07 Jan 2009 15:40:36 +0000
Cc:
Delivery-date: Wed, 07 Jan 2009 07:41:01 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4F65016F6CB04E49BFFA15D4F7B798D92D483E58@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclvyQrixVQbl8uESyOiS/TNP5uIqAAEbUEWABRCWuAACAQwRQAADgnwABZdSx8ADRKycAABHZ3+
Thread-topic: [Xen-devel] xen_phys_start for 32b
User-agent: Microsoft-Entourage/12.15.0.081119
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.

 -- Keir



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