From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5EF7CC4320D for ; Wed, 25 Sep 2019 06:56:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3E5F6217F4 for ; Wed, 25 Sep 2019 06:56:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2442412AbfIYG4z (ORCPT ); Wed, 25 Sep 2019 02:56:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36100 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404844AbfIYG4y (ORCPT ); Wed, 25 Sep 2019 02:56:54 -0400 Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0A8CDC04B31E for ; Wed, 25 Sep 2019 06:56:54 +0000 (UTC) Received: by mail-pf1-f199.google.com with SMTP id b204so3290156pfb.11 for ; Tue, 24 Sep 2019 23:56:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ijT0fpBaBgG6WmvEUpSA+esMu5WxoRviWQWfgADFoo4=; b=Z2G5CkaAOvBn+0XZb3sWcX3BK/DPf9qZGC6VlHyn5KE+egKotiZ2XgtJv4dl3FP7Tp 9myfxPID9MB589KVhoqsMtUJTXg4wMNa/4Cn0V2+YB/z3wssIuTKHMxJlZX2dJ2XDlCb hRypnf5M7w9apwjHseVScJ8nxKash0+c/guNWnRNeUfNXl7+IbkUmwk5la6rPkm01r4e ALcas/+/w4vobtAbZzFZIDBTnqE69AL0YTDEMNQJIVgVJIpVY1WptYoD9qq1XNqflXPk avWth29JXIuE61G7Aiv85VQ/KQ63knk33WfbgJQN2bBelWqsIPE2qBCB2a15o4/+KJmp 5EQw== X-Gm-Message-State: APjAAAWP523+sGnTjqbO01J8OT0WAvA+xfEcPg2LC/3uUwsajzXPyJ3h nGyTy+6u5FEujeu4pzq6qAQPCJ6SJiHdX8SCuauoj3OVngc2h1Ny7lVZ/GRbs8mbSVUvt+lnxs2 fH8P5Pd3kb1g11WfHLOQnH7vL X-Received: by 2002:aa7:91d4:: with SMTP id z20mr8178145pfa.131.1569394613574; Tue, 24 Sep 2019 23:56:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqyEQscMvlt2r5p9VzQw9b3ybPcThukuDsFI9KDVwsVjgxUw63WdPiTX25gqJqaKL+BCyIqXjg== X-Received: by 2002:aa7:91d4:: with SMTP id z20mr8178134pfa.131.1569394613417; Tue, 24 Sep 2019 23:56:53 -0700 (PDT) Received: from xz-x1 ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id g24sm6184543pgn.90.2019.09.24.23.56.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Sep 2019 23:56:52 -0700 (PDT) Date: Wed, 25 Sep 2019 14:56:40 +0800 From: Peter Xu To: Lu Baolu Cc: "Tian, Kevin" , "Raj, Ashok" , Jacob Pan , "kvm@vger.kernel.org" , "Kumar, Sanjay K" , "Sun, Yi Y" , "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , Alex Williamson , David Woodhouse Subject: Re: [RFC PATCH 0/4] Use 1st-level for DMA remapping in guest Message-ID: <20190925065640.GO28074@xz-x1> References: <20190923122454.9888-1-baolu.lu@linux.intel.com> <20190923122715.53de79d0@jacob-builder> <20190923202552.GA21816@araj-mobl1.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 25, 2019 at 10:48:32AM +0800, Lu Baolu wrote: > Hi Kevin, > > On 9/24/19 3:00 PM, Tian, Kevin wrote: > > > > > '-----------' > > > > > '-----------' > > > > > > > > > > This patch series only aims to achieve the first goal, a.k.a using > > first goal? then what are other goals? I didn't spot such information. > > > > The overall goal is to use IOMMU nested mode to avoid shadow page table > and VMEXIT when map an gIOVA. This includes below 4 steps (maybe not > accurate, but you could get the point.) > > 1) GIOVA mappings over 1st-level page table; > 2) binding vIOMMU 1st level page table to the pIOMMU; > 3) using pIOMMU second level for GPA->HPA translation; > 4) enable nested (a.k.a. dual stage) translation in host. > > This patch set aims to achieve 1). Would it make sense to use 1st level even for bare-metal to replace the 2nd level? What I'm thinking is the DPDK apps - they have MMU page table already there for the huge pages, then if they can use 1st level as the default device page table then it even does not need to map, because it can simply bind the process root page table pointer to the 1st level page root pointer of the device contexts that it uses. Regards, -- Peter Xu