|
xen-devel
RE: [Xen-devel] 32/64-bit hypercall interface
Jeremy Katz wrote:
> 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 fully agree that the same binary of 32bit paravirt guest be used
regardless of the HV flavor (i.e. 32-bit or 64-bit).
If we get the shadow mode working for those 32-bit paravirt guests, we
could avoid using 4-level page tables in the guest kernel (although the
processor actually uses 4-level page tables). In that case, however, we
will lose the good optimizations for paravirt guests, such as writeable
page tables and "late pin, early unpin." (but then we get the
save/restore/migration feature) There are other areas to look at, such
as, ring1 vs. ring3, but I think we can handle those in Xen.
>> 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
That's a very good point, and that way we could provide more complete
32-bit compatibility than the one we get on x86_64 Linux.
In terms of ABI/API, since Xen needs to disiguish 32-bit or 64-bit
guests anyway at runtime, I don't think we don't need to change the size
of any types at this point (i.e. before 3.0).
Jun
---
Intel Open Source Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home