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/
Home Products Support Community News


Re: [Xen-devel] question about the differences for xen in x86_32 and x86

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] question about the differences for xen in x86_32 and x86_64
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Fri, 31 Aug 2007 04:36:01 +0100
Delivery-date: Thu, 30 Aug 2007 20:36:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <464C1827.4020602@xxxxxxxxxx>
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>
References: <200705170825.l4H8PsrQ009170@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <464C1827.4020602@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6
> I am confused about the differences betwoon xen in x86_32 and x86_64
> in x86_32,Ring 1 for guest OS, ring3 for user-space, Xen lives in top
> 64MB of linear addr space, Segmentation used to protect Xen as switching
> page tables too slow on standard x86, Hypercalls jump to Xen in ring 0,
> Guest OS with ‘fast trap’ handler could direct user-space to guest OS
> system calls, is it right?

Yes, that's right.

> while in x86_64 ,both guestos and userapplications seem to run in ring3,
> and what about other thing memtioned above for x86_64? such as the
> memory mapping for xen and guestos kernel and applications , system call
> fast trap handling

Xen still lives at the top of the address space; I'm not sure how much it 
reserves for itself.  The guest kernel (when mapped) lives below Xen.  Guest 
userspace lives below that.

When running in guest usermode only the guest userspace and Xen are mapped 
into memory.  Xen is protected from guest userspace using the supervisor 
protection bit in the pagetables.

AFAIK, all system calls must bounce through Xen.  I don't think it's possible 
for OSes to take syscalls directly anymore.  This is because Xen has to map 
the guest kernel's pages into memory (by hooking an extra subtree into the 
current pagetable).  Xen then kicks the guest kernel into action; the kernel 
can directly access userspace pages since they are still mapped.  Xen is 
protected from the guest kernel by the supervisor protection bit in the 

When the kernel finishes its work it has to execute a hypercall to instruct 
Xen to transfer control back to userspace.  Xen has to flush the TLB at this 
point to remove the kernel mappings; otherwise it could be possible for the 
guest's userspace to interfere with the kernel's memory.

I believe the "global" bit is set on guest userspace pagetable entries, which 
means that the userspace mappings are not flushed at this point (performance 
optimisation).  Xen can still flush these mappings with a "global flush" if a 
switch of application running or of domain occurs.

> I am confused about it
> could you help me
> Thanks in advance

Hope that helps.


Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [Xen-devel] question about the differences for xen in x86_32 and x86_64, Mark Williamson <=