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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 246B5C07E9A for ; Wed, 14 Jul 2021 05:30:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EAD1F6136E for ; Wed, 14 Jul 2021 05:30:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237913AbhGNFdH (ORCPT ); Wed, 14 Jul 2021 01:33:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237802AbhGNFdG (ORCPT ); Wed, 14 Jul 2021 01:33:06 -0400 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63B82C0613DD for ; Tue, 13 Jul 2021 22:30:15 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id 22so1455432lfy.12 for ; Tue, 13 Jul 2021 22:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C3Z9CFxob2kEmCEAlCKWUPaU9hX+53zK6v4wQ2QlHFg=; b=VPTgdfil+GwXO7aZSuEge0uSYQQpIq8WFDOqaG4kz23mRyTm20rQHqJ6c9s9XXZR2d NDmm00L1EkY2wl7TcNTtMHSYWCjs7970YZtlzfApInzryHYZRQ8Wmn65qSFQpKv/JAbz l35cCt+Dzou82ybFA/qs2UQhP6a16jKNVg4z48ozplhKIzsp4+W7TvoLj/RDE7mvagKw 6SBHHeVgj4aBy24TfbEaTnyGJMCTI1XxY7uM+po33N5UcLNnT50dJunb9RlylUGPfI4X tx3Arba6kUxkzNCayOii13Hr2/rvB5I5BH7H+PxmDpPgFEw+OB9XeMQcGpl3iTnYUkaT gkBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C3Z9CFxob2kEmCEAlCKWUPaU9hX+53zK6v4wQ2QlHFg=; b=bpjRpIf2L1a6J21VUP0UKJ+TR7DC56rMCSNgAxkUyS7elDq8BhgWLXhZDIa/X3aKV8 pWjDPwBz891spgDqwO3DvsmAGn40Kv0HCmafPK1T/R3IBuGS5xM6VRghqqJZleYA/pK3 opJcDXN20WEhYozpQ1PLR2oAGozy8tkfO4e4ZBtMZBmVE4lE2wtCAics4waylBovW6x+ fvLoyflgJgp6emeYGDquuv0EW914zw2X/UNQVVcNWtJxk1IgEnkO+5yRNyeULLgIEt7s q9MuQTb89UauLpCFjdoFdJGeYpc9ZvzbSrxEVnIItwr1pJuWPj7mFYnF4xdeFbrGzz3w 3Byg== X-Gm-Message-State: AOAM532znL2pgnrS5I10RnuuAK6F8547g/tqK4JnR3Fc5N5/ExIzYYrL XjzHLiM+K2dLmhdvdvEbre7hSs6DhlZ2o7zYLHW7Aiu/rGQ= X-Google-Smtp-Source: ABdhPJzwGzp1+TAupobQLPbG3N+XphKRuUSDwilCNDvuT3/BEtaVEVbBuQflBmok1a5NdcLA6b+zt0OuoEJ3TExFYWg= X-Received: by 2002:a19:5f43:: with SMTP id a3mr6316001lfj.504.1626240613790; Tue, 13 Jul 2021 22:30:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: harry harry Date: Wed, 14 Jul 2021 00:30:12 -0500 Message-ID: Subject: Re: About two-dimensional page translation (e.g., Intel EPT) and shadow page table in Linux QEMU/KVM To: Sean Christopherson Cc: Maxim Levitsky , kvm@vger.kernel.org, qemu-devel@nongnu.org, Sean Christopherson , Paolo Bonzini , stefanha@redhat.com, mathieu.tarral@protonmail.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Dear Sean, Thanks for the comments! > Heh, because the MMUs are all per-vCPU, it actually wouldn't be that much effort > beyond supporting !TDP and TDP for different VMs... > Sorry, may I know what do you mean by "MMUs are all per-vCPU"? Do you mean the MMUs walk the page tables of each vCPU? > ...but supporting !TDP and TDP in a single KVM instance isn't going to happen. > It's certainly possible, but comes with a very high complexity cost, and likely > even performance costs. For one KVM instance, I think it might be possible to let several physical cores use !TDP and other cores use TDP but I am not sure about the implementation complexity. > > The more sane way to support !TDP and TDP on a single host would be to support > multiple instances of KVM, e.g. /dev/kvm0, /dev/kvm1, etc... Being able to use > !TDP and TDP isn't strong justification for the work required, but supporting > multiple KVM instances would allow upgrading KVM without having to migrate VMs > off the host, which is very desirable. If multiple KVM instances are supported, > running !TDP and TDP KVM instances should Just Work. Yes, for different KVM instances, it may be much easier but there might be some other issues, e.g., communication overhead between different instances. I think the upgrading idea is great but is very limited to local upgrading. Best, Harry 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 EDABBC07E9A for ; Wed, 14 Jul 2021 05:31:26 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 59336613B0 for ; Wed, 14 Jul 2021 05:31:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 59336613B0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:50916 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m3XUT-0003fv-FP for qemu-devel@archiver.kernel.org; Wed, 14 Jul 2021 01:31:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49312) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m3XTN-0002kU-FG for qemu-devel@nongnu.org; Wed, 14 Jul 2021 01:30:17 -0400 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]:33595) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m3XTL-0004rQ-IQ for qemu-devel@nongnu.org; Wed, 14 Jul 2021 01:30:17 -0400 Received: by mail-lf1-x133.google.com with SMTP id t17so1586632lfq.0 for ; Tue, 13 Jul 2021 22:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C3Z9CFxob2kEmCEAlCKWUPaU9hX+53zK6v4wQ2QlHFg=; b=VPTgdfil+GwXO7aZSuEge0uSYQQpIq8WFDOqaG4kz23mRyTm20rQHqJ6c9s9XXZR2d NDmm00L1EkY2wl7TcNTtMHSYWCjs7970YZtlzfApInzryHYZRQ8Wmn65qSFQpKv/JAbz l35cCt+Dzou82ybFA/qs2UQhP6a16jKNVg4z48ozplhKIzsp4+W7TvoLj/RDE7mvagKw 6SBHHeVgj4aBy24TfbEaTnyGJMCTI1XxY7uM+po33N5UcLNnT50dJunb9RlylUGPfI4X tx3Arba6kUxkzNCayOii13Hr2/rvB5I5BH7H+PxmDpPgFEw+OB9XeMQcGpl3iTnYUkaT gkBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C3Z9CFxob2kEmCEAlCKWUPaU9hX+53zK6v4wQ2QlHFg=; b=HEgbSUwNy2i3wBkCFuBFq6PIvBDIouDVFQFhGqTr6nxLq1sfqOyo8hlmooFsSiE2wT +YsXUHFDHEFEG7qGZmTXRIVECvVRPICtL2JTQNqvqr272b9K85DpkfiKkuROZSxPqf2o mHci7ABLz8FNm64rl9LXHOjJgTS3YWceehf+AEuHW4S5E95eL1EHY6AOqjhXdUvRY0/g OjdKYCiLU7Sn5P5MZvjJu7ySx6obAvaaFLMy9jsvNa2a16WkSarSR9gv8KjJKqOElLDb 56GN6hHFvBTkEQw/OvEQY6Lrf2xyaLUF3Dz5Mh9irYXxYKHHnliq0LfGj8pCsA1yW0fJ IBFQ== X-Gm-Message-State: AOAM5337x/J92kFcMJAmdIjLr/UwLQoif/qOCU27dfT9XiwYydkbHaqQ sNGGh0KhcJtUL8fi3mI8RgL9ETxhtolzd8PQNLI= X-Google-Smtp-Source: ABdhPJzwGzp1+TAupobQLPbG3N+XphKRuUSDwilCNDvuT3/BEtaVEVbBuQflBmok1a5NdcLA6b+zt0OuoEJ3TExFYWg= X-Received: by 2002:a19:5f43:: with SMTP id a3mr6316001lfj.504.1626240613790; Tue, 13 Jul 2021 22:30:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: harry harry Date: Wed, 14 Jul 2021 00:30:12 -0500 Message-ID: Subject: Re: About two-dimensional page translation (e.g., Intel EPT) and shadow page table in Linux QEMU/KVM To: Sean Christopherson Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::133; envelope-from=hiharryharryharry@gmail.com; helo=mail-lf1-x133.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, Sean Christopherson , Maxim Levitsky , mathieu.tarral@protonmail.com, stefanha@redhat.com, Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Dear Sean, Thanks for the comments! > Heh, because the MMUs are all per-vCPU, it actually wouldn't be that much effort > beyond supporting !TDP and TDP for different VMs... > Sorry, may I know what do you mean by "MMUs are all per-vCPU"? Do you mean the MMUs walk the page tables of each vCPU? > ...but supporting !TDP and TDP in a single KVM instance isn't going to happen. > It's certainly possible, but comes with a very high complexity cost, and likely > even performance costs. For one KVM instance, I think it might be possible to let several physical cores use !TDP and other cores use TDP but I am not sure about the implementation complexity. > > The more sane way to support !TDP and TDP on a single host would be to support > multiple instances of KVM, e.g. /dev/kvm0, /dev/kvm1, etc... Being able to use > !TDP and TDP isn't strong justification for the work required, but supporting > multiple KVM instances would allow upgrading KVM without having to migrate VMs > off the host, which is very desirable. If multiple KVM instances are supported, > running !TDP and TDP KVM instances should Just Work. Yes, for different KVM instances, it may be much easier but there might be some other issues, e.g., communication overhead between different instances. I think the upgrading idea is great but is very limited to local upgrading. Best, Harry