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] RE: Xen/ia64 presentation

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Hollis Blanchard" <hollisb@xxxxxxxxxx>
Subject: RE: [Xen-devel] RE: Xen/ia64 presentation
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Thu, 28 Apr 2005 22:53:32 +0800
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 28 Apr 2005 14:53:26 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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: AcVLKPB5xi7IHwTKQBibGXJhrYRpvAAGjpWwAC18PtA=
Thread-topic: [Xen-devel] RE: Xen/ia64 presentation
Magenheimer, Dan (HP Labs Fort Collins) wrote:
> Maintaining close ties to Linux makes it much easier to "go back to
> the well".  I remember that Xen 1.0 removed a lot of the early
> "start of day" code for other (e.g. Cyrix) processors; when the
> user community grew and some users wanted to run on other processors,
> the Xen team went back and grabbed the code from Linux.  When the
> ACPI tables needed to be more fully parsed, the Xen team grabbed
> the ACPI code from Linux.  Recently, when I needed to add "user
> access" capability to Xen/ia64, I grabbed the exception table code
> from Linux/ia64 (and Linux common code); it basically just worked, in
> part because Keir had grabbed the x86 equivalent code earlier.
> 
Hi, Dan:
        "user access"  capability probably is not a right example. I
think you are talking about the mechanism to support Hypercall parameter
passing that you call it as poorman's exception handler mechanism. As we
discussed before, this mechanism will trigger guest tlb fault when the
TC map carrying guest hypercall information went away. This cause
following critical problem:
        1: When this hypercall is invoked in guest vpsr.ic=0, it will
trigger nested tlb miss which the guest can never handle.
        2: If the hypercall is invoked in guest tlb miss handler,
injecting guest tlb miss may cause endless (recursive) guest tlb miss->
hypercall -> guest tlb miss...

        The possible solution to this issue is to use either guest TR
map or guest special map (always reside in guest TLB) for the area
carrying hypercall information so that the map for this area will never
go away and thus the special "user access" mechanism that linux uses is
not necessary again. (In linux sitiuation, the user application never
run in vspr.ic=0 nor tlb miss handler)
Thanks,eddie

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

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