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-ia64-devel

[Xen-ia64-devel] TR virtualization vs. DCR

To: <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-ia64-devel] TR virtualization vs. DCR
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Wed, 12 Oct 2005 16:35:15 +0800
Delivery-date: Wed, 12 Oct 2005 08:38:11 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXPB95t54bLKTGyS36TzqawX8bcEQ==
Thread-topic: TR virtualization vs. DCR

Dan and All:

     Currently both VTI and non-VTI are using machine TC to emulate guest TR, that is a must as machine memory a guest get may be discontiguous and may not be proper aligned. But this introduces another extra issues for guest ld.s.

     A guest ld.s to a TR mapped address will always be success, but in TC emulated TR, it may fail. Hypervisor is OK to handle that if it get control (i.e tlb miss), but in some situation, machine side may meet the exception deferral condition that cause the execution directly get returned with wrong value in target register (NAT is set). It is probably OK with C compiler generated code as there is chk.s to recover, but for an assembly wrote code with ld.s especially in guest kernel, we have problem.

     A right way to deal with that is to let machine side have much tighter deferral condition than guest side so that HV can get trapped always if it is needed and handle them. This introduces the DCR virtualization policy. Current non-VTI approach doesnt write any guest DCR information to machine side, we are just lucky now, while VTI approach is directly writing to machine DCR (dcr.pp is virtualized).
     In order to support this, DCR needs to be virtualized, to minimize this, only dcr.dm bit needs to be virtualized, i.e machine DCR.dm=0 while all other bits are same with guest (dcr.pp is another one need to be virtualized).

     Any comments?

Eddie

 

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
<Prev in Thread] Current Thread [Next in Thread>