On Tue, Feb 05, 2013 at 11:02:32AM -0800, David Daney wrote: > Hi, > > I am starting to working on a port of KVM to an architecture that > has a dual TLB. The Guest Virtual Addresses (GVA) are translated to > Guest Physical Addresses (GPA) by the first TLB, then a second TLB > translates the GPA to a Root Physical Address (RPA). For the sake > of this question, we will ignore the GVA->GPA TLB and consider only > the GPA->RPA TLB. > > I seems that most existing ports have a bunch of custom code that > manages the GPA->RPA TLB and page tables. > > Here is what I would like to try: Create a mm for the GPA->RPA > mappings each vma would have a fault handler that calls gfn_to_pfn() > to look up the proper page. In kvm_arch_vcpu_ioctl_run() we would > call switch_mm() to this new 'gva_mm'. gfn_to_pfn uses the address space of the controlling process. GPA->RPA translation does: 1) Find 'memory slot' (indexed by gfn) 2) From 'memory slot', find virtual address (relative to controlling process). 3) Walk pagetable of controlling process and page retrieve physical address. > Upon exiting guest mode we > would switch back to the original mm of the controlling process. > For me the benefit of this approach is that all the code that > manages the TLB is already implemented and works well for struct > mm_struct. The only thing I need to do is write a vma fault > handler. That is a lot easier and less error prone than maintaining > a parallel TLB management framework and making sure it interacts > properly with the existing TLB code for 'normal' processes. > > > Q1: Am I crazy for wanting to try this? You need the mm_struct of the controlling to be active, when doing GPA->RPA translations. > Q2: Have others tried this and rejected it? What were the reasons? I think you'll have to switch_mm back to the controlling process mm on every page fault (and then back to gva_mm). > > Thanks in advance, > David Daney > Cavium, Inc. 'vma' `is a process > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
