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] TLB-miss handling in Xen 3.0

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] TLB-miss handling in Xen 3.0
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Thu, 2 Mar 2006 23:57:48 +0000
Cc: Amitayu Das <amitayudas@xxxxxxxxx>
Delivery-date: Fri, 03 Mar 2006 00:03:57 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <5f74ce410603021327n6e7f3822o891f1ef657a9e32c@xxxxxxxxxxxxxx>
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: <5f74ce410603021327n6e7f3822o891f1ef657a9e32c@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.1
> 1. Each guest-OS has got a *physical-to-machine* table where as the
> hypervisor has got a globally readable
> *machine-to-physical* table.
>
> My questions are the following:
>
> 1. An unmodified linux guest-OS would have *virtual-to-physical* mapping in
> its page-table. Given the    need of para-virtualization,
>    does it have a *virtual-to-machine* mapping as well in addition to the
> mapping talked about in the interface manual?

Paravirt guests build pagetables that map virtual to machine addresses.  To 
ease the effort of porting, much of the guest code uses "physical" addresses, 
which are translated to machine addresses using the P2M table before being 
installed into the page tables.  So actually, guest pagetables are a 
virtual-to-machine mapping.

Unmodified guests under VT-x/SVM don't do this, so Xen implements an extra 
level of indirection called "shadow pagetables".  The guest is permitted to 
create a "virtual-to-physical" table, and Xen maintains a "shadow" which 
implements "virtual-to-machine" translations and can be used directly by the 
hardware.

> 2. If there exists such a *virtual-to-machine* mapping for a guest-OS
> (assuming the anwer to Q1 is "yes"), what happens for TLB miss for a
> process running inside a guest-OS?
>     If the hypervisor is responsible for the update, is it aware of virtual
> address associated with a process running inside a guest-OS and how   does
> he do it? If any hardware circuitry is responsible for doing that, is it
> aware of
>     virtual address associated with a process running inside a guest-OS and
> how does he do it?

On x86, a TLB miss causes the CPU to walk the page tables and fill in the TLB 
entry itself.  This works as normal, without a trap.

For paravirt guests, because the guest fills out the page tables directly with 
machine addresses.  The processor uses the addresses in the guest pagetable 
directly.

For unmodified guests, Xen builds shadow pagetables that translate from guest 
virtual to real machine addresses, so the CPU uses these directly.  In this 
case, the pagetables created by the guest are never used directly.

HTH,
Mark

-- 
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>