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