[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Biemueller, Sebastian" <Sebastian.Biemueller@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Tue, 15 May 2007 11:09:40 +0100
  • Delivery-date: Tue, 15 May 2007 03:08:11 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceW195aW8skL4OXRuq5UwVa+odMXQAAUgQF
  • Thread-topic: [Xen-devel] [PATCH][HVM][SVM] Reintroduce ASIDs.

Hi Sebastian,

Nice work, but please resync to staging tip of xen-unstable.
http://xenbits.xensource.com/staging/xen-unstable.hg.

We haven't pushed to the main tree for a while now due to various issues, so
there'll be some merging to do.

 Thanks,
 Keir

On 15/5/07 11:00, "Biemueller, Sebastian" <Sebastian.Biemueller@xxxxxxx>
wrote:

> 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(-
> 
> 
> 
> Regards,
> 
>  Sebastian
> 
> 
> 
> References:
> 
> [1] Presentation given at the XenSummit Spring, 2007
> http://www.xensource.com/files/xensummit_4/2007XenSummit-AMD-ASIDS-Biemueller.
> pdf
> 
> [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
> generations.
> 
> 
> --
> 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
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.