RE: [Xen-devel] RE: Xen/ia64 presentation

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

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