From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Daney Subject: Q: Why not use struct mm_struct to manage guest physical addresses in new port? Date: Tue, 05 Feb 2013 11:02:32 -0800 Message-ID: <51115748.2090203@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ralf Baechle To: KVM devel mailing list Return-path: Received: from mail-ie0-f169.google.com ([209.85.223.169]:43927 "EHLO mail-ie0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756109Ab3BETCf (ORCPT ); Tue, 5 Feb 2013 14:02:35 -0500 Received: by mail-ie0-f169.google.com with SMTP id 13so722318iea.0 for ; Tue, 05 Feb 2013 11:02:34 -0800 (PST) Sender: kvm-owner@vger.kernel.org List-ID: 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'. 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? Q2: Have others tried this and rejected it? What were the reasons? Thanks in advance, David Daney Cavium, Inc.