[Xen-ia64-devel] RE: Xen/ia64 - global or per VP VHPT

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

>       Actually we have designed the rid virtualization 
> mechanism but is not in this implementation yet. Actually in 
> this area we don't have difference between your approach 
> (starting_rid/ending_rid for each domain) and high 4 bits 
> indicating domain ID.  Merge this problem is quit easy.

Good!

>             I am afraid supporting for both solution is 
> extremely high burden as VMMU is a too fundmental thing. For 
> example: How to support hypercall information passing between 
> guest and HV? You are using poorman's exception handler now 
> that is OK for temply debug effort. But as we discussed, it 
> has critical problem/limitations. 

Um, no, it has critical problems/limitations for VT domains.
I don't see the same problems with non-VT.  But since we
don't want to have different hypercall APIs for VT and non-VT,
I agree that hypercall parameters should be passed in memory.

I don't think this applies to "global VHPT vs per-domain VHPT"
as this should be completely invisible to guestOS.  And I
think it should be possible (fairly easy) to support both:
per-domain for VT domains and global for non-VT.

>       The solution to solve that in our vMMU is that we keep 
> all guest TLBs in HV internal data structure, and we have 
> defined a seperate TLB section type like ForeignMap(Term in 
> X86 XEN)/Hypercall sharedPage in vTLB. Xenolinux or Device 
> model or others can insert special maps for that. This type 
> of section will not be automatically purged when the 
> collision chain is full. In this way guest will not see tlb 
> miss for "uaccess" in HV to access guest data.
>       How to solve that in global VHPT? I am afraid it is 
> really hard. Why do we want to spend more time to discard 
> existing approach and investigate on no hints direction?
> 
>       BTW, how do you support MMIO map for DOM-N if the 
> domain-N is a non modified Linux? I am afraid global VHPT 
> will also eventually need a similar vTLB data struture to support.

These are good questions for a VT domain.  Its not clear if/how
they apply for non-VT.

I'm not arguing that VT domains should use a global VHPT,
I'm arguing that non-VT domains can.   It may prove that
per-domain works better for non-VT too, but I want to
preserve the option to explore that.

Dan

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