[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |