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

RE: [Xen-devel] 32/64-bit hypercall interface

On Sat, 2005-10-01 at 11:25 -0700, Nakajima, Jun wrote:
> Jeremy Katz wrote:
> > On Fri, 2005-09-30 at 17:42 +0100, Keir Fraser wrote:
> >> There's the rub: we don't expect to ever want to provide 32-bit x86
> >> ABI compatibility on 64-bit x86 Xen. We will not be supporting 32-bit
> >> paravirtualised guests on 64-bit x86 Xen,
> > 
> > ... which I've previously said and continue to think is going to be
> > something that will eventually be regretted.  People are going to want
> > to continue to run in a 32bit OS for legacy reasons for quite a while
> > (even with the compatibility you get on x86_64).  Making it so they
> > can't do mix and match of 32 and 64 bit guests on a single host is
> > going to significantly reduce the utility of Xen.

> That's mostly because of the H/W issues. One thing we could do there is
> to run such  paravirtualised 32-bit guests in compatibility mode. But
> they would need to use 4-level page tables, and there are other minor
> differences. So those 32-bit guests wouldn't be really same as the ones
> running on 32-bit Xen. I'm not sure that's what you wanted, but it's
> doable.

You really want to get to the same 32bit paravirt guest being used
regardless of what HV flavor you're running.  Otherwise, you're in for a
compatibility nitemare.  What dictates that the guest has to know about
the 4 level page tables?  That's like saying that your 32bit binaries
running on 64bit Linux need to know that there is a larger address space
when instead that gets handled by the kernel.

> I think a better way is to utilize H/W-based virtualization such as
> Intel Virtualization Technology (VT) or AMD's Pacifica. That way we
> should be able to use the same binaries (thus ABI) for both 32-bit
> non-PAE and PAE domU on 64-bit x86 Xen. With H/W-based virtualization we
> can run those 32-bit guests cleanly in 32-bit on 64-bit Xen. 32-bit
> hypercalls from such 32-bit guests should be intercepted by a 32-bit
> ring0 component that converts "int 0x82" based ones to VMCALL or VMMCALL
> sent to 64-bit Xen (because such software interrupts won't cause
> VMEXIT). There are other issues like impacts to the memory management in
> Xen, but I think those can be handled as special cases of shadow mode
> (i.e. don't make shadow pages). I don't think it would increase the
> utility of Xen right away (because this requires new processors), but it
> might be a sensible thing to do in the near future.

Right, the problem is that people have bought hardware and they're going
to want to use it.  I think that having things work on the hardware I've
already purchased will help to give people a much better migration path
for the future.  If I'm going to have to run my legacy 32bit stuff on a
different machine anyway, then I can feel more free to look at other
platforms for my "future" stuff.

Jeremy


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