Re: [Xen-devel] Hypercall interface changes for PAE

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 31 May 2005, at 20:02, Gerd Knorr wrote:

> That certainly would be the way to go if we want to have
> different interfaces for PAE and non-PAE.  I'm not sure it
> is a good idea to have different hypercall interfaces for
> PAE and non-PAE cases in the first place.
>
> What does this mean for the tools?  Would these also be
> either PAE or non-PAE then?
At least some parts of the tools (e.g., libxc) will need re-building 
for PAE as they know about the structure of pagetables (2-level vs. 
3-level and so on). Either that or we need to compile both cases into 
the library and auto-switch between implementations of some functions 
at run time. Either way, this problem isn't solved by making the mmu 
hypercalls 'binary compatible' across pae/non-pae.
If we really do care about compatibility across pae/non-pae, I would do 
this by making the pte_val a u64 in all cases rather than splitting pfn 
from flags. Then everyone would just ignore the upper 32 bits on 
non-pae systems. This would waste no more space than 32-bit pfn + 
32-bit flags.
I'm fairly neutral on this: if we're happy to make definitions of 
things like pte's and physaddr's be u64 even on non-pae then that may 
help binary compatibility in future at probably very little cost here 
and now. OTOH we can't be fully binary compatible without shadow 
pagetables anyway, because the pagetable structure differs, so is the 
effort worth it?
> What about the option to maybe run non-PAE guests in PAE-xen
> in some translated shadow mode?  That wouldn't work then.
> I don't think this would be a big problem though ...
I think we can live without this. But even if not then we haven't burnt 
our bridges -- we could redirect those few hypercalls to a very slim 
compatibility layer.
 -- Keir


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