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

[Xen-devel] Question about implementation of 32-bit guests on 64-bit hyp

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Question about implementation of 32-bit guests on 64-bit hypervisor (IDT-related)
From: "Vessey, Bruce A" <Bruce.Vessey@xxxxxxxxxx>
Date: Fri, 7 Dec 2007 08:05:33 -0600
Delivery-date: Fri, 07 Dec 2007 06:07:34 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acg42jutUGLFo8UAStSnH+76P8iWCA==
Thread-topic: Question about implementation of 32-bit guests on 64-bit hypervisor (IDT-related)
In a recent conversation one of my coworkers raised a concern about
memory limitations when running 32-bit guests on top of the 64-bit
hypervisor.  At this point the discussion is academic; I don't know
when/if we'll ever be able to get system resources to test it, to see if
the concerns that he expressed are real.  So I decided to post this in
hope of getting comments from the people who worked in this area.  (I
apologize in advance if this is not a proper usage of this mailing list.
In that case, which mailing list would be correct?)

The discussion went as follows.  It seems that there are two ways to
support a 32-bit guest on top of a 64-bit Monitor. We're not familiar
enough with the Xen code to know which Xen uses.  The first method
involves running the guest in compatibility mode (64-bit environment
that executes code the same way as a 32-bit processor), and the second
method is to run the guest in native 32-bit mode.

If the guest is run in compatibility mode, the processor will use 64-bit
page tables, which will allow the guest RAM to be placed anywhere within
the physical address space (on current processors, this is 0-1TB). This
seems like the ideal solution, but unfortunately there is a catch. If
the processor is in compatibility mode, the IDT and interrupt handler
functions must all be 64-bit compatible. Since the 32-bit guest will
attempt to load a 32-bit IDT, the hypervisor would have to substitute a
64-bit IDT. This seems to be extremely dangerous, because the
substituted IDT would have to work exactly like the guest's original
32-bit IDT, and there is a possibility that any kernel updates or
service packs to the guest OS would require changes in the substituted
64-bit IDT. 

The alternative is to run the guest in native 32-bit mode. This would
allow the 32-bit IDT provided by the guest OS to be used. However, this
also means that the page tables that are in effect when the guest runs
(the Shadow Page Table) must be either plain 32-bit, or PAE 32-bit.  PAE
seems like an obvious choice, since it is safe to use PAE "under the
hood" even if the guest is non-paging or non-PAE. The problem with this
solution is that PAE page tables only have enough space in the entries
to designate a maximum hardware physical address of 64GB. (Our systems
go substantially larger.)  So the hardware physical locations of the
Guest RAM for all 32-bit guests would have to be located within the
first 64GB.

My questions are:

(1)  Which approach does Xen use?  Is it one of the above, or yet
something else?

(2)  What are the configuration restrictions, if any, for running 32-bit
guests on top of the 64-bit hypervisor?

Thanks for your time and assistance.

    - Bruce

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