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] RE: A patch to remove dcr.63 for running_on_xenindi

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Subject: RE: [Xen-ia64-devel] RE: A patch to remove dcr.63 for running_on_xenindicator
From: "Yang, Fred" <fred.yang@xxxxxxxxx>
Date: Wed, 31 Aug 2005 09:00:16 -0700
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 31 Aug 2005 15:58:18 +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: AcWYaSAKDEpFITOYRmOMPwJnp5q9pQAADjIQADg3V1AALzs7IAAA1IBAAJG2/gAAqDjkoAAncIggAKI8w2AC5B7eAAAHRMkAAB4i15AAAMA8sA==
Thread-topic: [Xen-ia64-devel] RE: A patch to remove dcr.63 for running_on_xenindicator
Magenheimer, Dan (HP Labs Fort Collins) wrote:
>>      The reason to push this patch is that bit 63 of DCR may
>> be not reserved in future just like PSR.vm bit in VT-i spec.
>> Probing shared memory is just much safe.
> 
> While it is true that bit 63 of the DCR is architecturally
> reserved, we will probably have several years of notice
> if it is actually going to be architecturally-defined in
> a future IPF implementation.  (If you know that it is
> definitely going to be defined in an IPF chip before
> 2010, please let me know and we certainly can choose a
> different bit.)
For software development, it should never use hardware reserved fields.
What if each software doing design base on its own preference to use
hardware reserved bits differently, then how can processor maintain
software backward compatibilities?  A software doing these short term
design may not runable a couple years later!
Pull in the shared page checking code doesn't break the existing design,
rather it provides a better sanity checking should we move to flexible
shared page and not break hardware specification
> 
> I intend to utilize dynamic configurable shared memory address
> within the next 6-12 months.
It seems you already have some mechanism to make shared memory flexible,
please share the idea.

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

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