| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
RE: [Xen-ia64-devel] RE: A patch to remove dcr.63 for running_on_xenindi
> > 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!
Its not using a hardware reserved field. Its defining
a virtual dcr where bit 63 has a different meaning. Many
virtualized privileged register bits have different semantics
than the equivalent hardware registers.
There are many architectural assumptions made by Xen (both
x86 and ia64). If the architecture changes in any substantial
way (including for example future versions of VT), newer
versions of Xen will be required. Although I understand
and am completely supportive of Intel's absolute track record
of backwards compatibility for applications, I am very
skeptical that all future Intel chips will guarantee
backwards compatibility for legacy hypervisors.
In any case, I am not insisting on using dcr bit 63 or
any other reserved bit. I am just insisting that we not
use a fixed shared page virtual address.
> 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
It doesn't break the existing implementation but it does
break the existing design.
> > 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.
The pseudo-code snippet in my previous message (plus corresponding code
in the hypervisor) makes it flexible. Virtually all references
in Xen/ia64 to the shared page are indirect through
arch_vcpu_info.privregs
(which is a pointer). There are a few places in hyperprivop.S and
xenasm.S
(and one in ivt.S) where I was lazy and used the hard-defined location,
but these can be easily fixed. (Try
"find xen | xargs grep XSI_ | grep -v OFS | grep -v asm-" )
This is because the design is for the shared page address to be
dynamically
configurable. Once these few places are fixed, we can remove all
the DEFINEs in asm-xsi-offsets.c that use SHARED_ARCHINFO_ADDR
(and the two places in all of Xen/ia64 where this constant is
used... I was lazy for those two places too :-) The constant
SHARED_ARCHINFO_ADDR can remain as a default for guests that
don't choose to make a hypercall to specify another virutal address.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home