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


[Xen-devel] [PATCH][HVM][SVM] Reintroduce ASIDs.

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [PATCH][HVM][SVM] Reintroduce ASIDs.
From: "Biemueller, Sebastian" <Sebastian.Biemueller@xxxxxxx>
Date: Tue, 15 May 2007 12:00:29 +0200
Delivery-date: Tue, 15 May 2007 02:59:50 -0700
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: AceW195aW8skL4OXRuq5UwVa+odMXQ==
Thread-topic: [PATCH][HVM][SVM] Reintroduce ASIDs.
This patch reintroduces ASID management for AMD-V.  This work was presented on 
the last XenSummit [1].

Short overview:

ASIDs partition the physical TLB for SVM.  In the current implementation ASIDs 
are used to reduce the number of TLB flushes.  Each time the guest's virtual 
address space changes (e.g. due to an INVLPG, MOV-TO-{CR3, CR4} operation), 
instead of flushing the TLB, a new ASID is assigned.  This reduces the number 
of TLB flushes to at most 1/#ASIDs (currently 1/64).  The biggest advantage is 
that hot parts of the hypervisor's code and data remain in the TLB.

Sketch of the Implementation:

ASIDs are a CPU-local resource.  As preemption of ASIDs is not possible, ASIDs 
are assigned in a round-robin scheme.  To minimize the overhead of ASID 
invalidation, at the time of a TLB flush, ASIDs are tagged with a 64-bit 
generation.  Generation overflows are designed not to happen and thus not 
optimized. (They appear at most every 2^80 cycles).  Here ASIDs are simply 
disabled to retain correctness [2].

b/xen/arch/x86/hvm/svm/asid.c        |  181 ++++++++++++++++++++++++++++++++
b/xen/include/asm-x86/hvm/svm/asid.h |  162 +++++++++++++++++++++++++++++++
xen/arch/x86/cpu/amd.c               |    4 
xen/arch/x86/hvm/svm/Makefile        |    1 
xen/arch/x86/hvm/svm/svm.c           |   41 ++++++-
xen/arch/x86/hvm/svm/vmcb.c          |    8 -
xen/arch/x86/hvm/svm/x86_32/exits.S  |    7 +
xen/arch/x86/hvm/svm/x86_64/exits.S  |    7 +
xen/include/asm-x86/hvm/svm/vmcb.h   |    5 
9 files changed, 401 insertions(+), 15 deletions(-




[1] Presentation given at the XenSummit Spring, 2007

[2] The 2^80 cycles result from: 1. And VM-Entry/-Exit cycle takes at least 
1800 cycles (approximated by 2^10) 2. We have 64 ASIDs (2^6)  3. 2^64 

AMD Inc.
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG 
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland 
Registergericht Dresden: HRA 4896 
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy

Attachment: svm_asid_against_cs15017.patch
Description: svm_asid_against_cs15017.patch

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>