Re: Hypercall interface changes for PAE

[Gerd Knorr <kraxel@suse.de>]

On Tue, May 31, 2005 at 08:23:38PM +0100, Keir Fraser wrote:
> 
> 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.

Disclaimer: Havn't even looked at the tools code yet.

I'd expect with a identical interface we'll only have to add a
PAE-enabled domain builder to boot domU (there are multiple
already anyway, right?), whereas with different interfaces the
split goes down to the shared lib which provides the hypercall
interface to the tools.

Point is I expect it being much easier to switch at runtime
between pae and non-pae in the tools when the hypercall
interface is identical.  I might be wrong on this though.

> 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.

Agreed.

> >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.

I'd prefeare 64-bit everythere over a compatibility layer.

What about VT/Pacifica btw?  As far I know the x86_64 guys plan
to allow 32-bit vmx guests, right?  I think to make that work
xen must be able to translate non-PAE page table entries into
x86_64 tables (which are very simliar to PAE).  If this
translation code is present anyway it's probably only a small
step to allow non-PAE guests in PAE mode as well.  If we get
this almost for free we might just implement it, although I see
this more as a "nice-to-have" feature that something really
important.

  Gerd

-- 
-mm seems unusually stable at present.
	-- akpm about 2.6.12-rc3-mm3