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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB537C0015E for ; Thu, 29 Jun 2023 16:50:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231953AbjF2Qul (ORCPT ); Thu, 29 Jun 2023 12:50:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231508AbjF2Qui (ORCPT ); Thu, 29 Jun 2023 12:50:38 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C23630F1 for ; Thu, 29 Jun 2023 09:50:37 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5618857518dso6988207b3.2 for ; Thu, 29 Jun 2023 09:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688057436; x=1690649436; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=P7X1f1JkCDNqEyBhjNE0NVCYk7dv7XgPQ/wMLYU+XyQ=; b=a6lSBajW3W02rYZGgR3/o0i9lxzRFVovXoe3Q3JaBs8FdTwqUBneab7VBjiCfUhcLA 0ufpIbSR4EeP/geTQzfXNnnIbTwqIf0t30LMWe6PpIWGthQ/XTooya1lmeGiSvs6YA5S mswOiz4kIhsywRvIn1fanIuT6NZHga1wspana2xVtBxT5giHdB7sN6MIVZl44cmlJnNO 1CGKzS+KzlyEF3Q2aNAESdMDCcdGN0e8CIBhnwCbVpSChU+zztHsa7BZhyNcGQZmHaPF L9/xLJSMfJm4abmW4kcT3CxN4cTptlZaENvbIcJ9kj1ojgO1prkD1YbHNJi4caKPO1dv 6E7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688057436; x=1690649436; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=P7X1f1JkCDNqEyBhjNE0NVCYk7dv7XgPQ/wMLYU+XyQ=; b=hb7SIcdl29vp+r73Mz6Yl6TPKv2/yM7XTVXwMKJ4YSR+zrK4fpan2tT3Q/FXXajbqI prpD08J/BcKSQ5SP/RxQA+YE4+xW29Y/htb54HuNkuAu7iEuOcmZkqz9/QpwSFmLwvZL caDvYd/DrsaOhdnDCMXPQBuObcYKBxDxiMhqtJEwNluvxAKDnfE2QmFyBQyps1PqmfOg Y0ivMnWrKQBJdYvyo9PmNjD5JN8Vv10Kq+rIwuz7QwAja5ewYsV5euQPxheJk7PN0DWs tDKEqKym0E5dEUlO6gDeaz4hi3uZXjJIP360dmsEgwTdsRbwMwofbHnURK8Kc5rpfCwX 801g== X-Gm-Message-State: AC+VfDyZFZQlGzNTH7qsCKPq5EeVIRfF7aNtpDo1rGIH1D3PoBr4/RVa ltO+so4cPn9sqqrvuBe0bHexkLVXy5k= X-Google-Smtp-Source: ACHHUZ4lX+OOByfNcIUyoAakFmq15S+MSm5QkF+XEVSIc/gfVC4dKYToyRXyN+5uRHV6F/tF6oW/LjK/pqc= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:b647:0:b0:56d:3c2b:2471 with SMTP id h7-20020a81b647000000b0056d3c2b2471mr15652904ywk.3.1688057436218; Thu, 29 Jun 2023 09:50:36 -0700 (PDT) Date: Thu, 29 Jun 2023 09:50:34 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230217231022.816138-1-seanjc@google.com> <20230217231022.816138-9-seanjc@google.com> <20230221152349.ulcjtbnvziair7ff@linux.intel.com> <20230221153306.qubx7tfmasnvodeu@linux.intel.com> <20230222064931.ppz6berhfr4edewf@linux.intel.com> Message-ID: Subject: Re: [PATCH 08/12] KVM: nSVM: Use KVM-governed feature framework to track "vVM{SAVE,LOAD} enabled" From: Sean Christopherson To: Yu Zhang Cc: Paolo Bonzini , Vitaly Kuznetsov , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Maxim Levitsky Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 22, 2023, Sean Christopherson wrote: > +Maxim > > On Wed, Feb 22, 2023, Yu Zhang wrote: > I'll opportunistically massage the comment to make it more explicit about why > VMLOAD needs to be intercepted. > > That said, clearing the bits for this seems wrong. That would corrupt the MSRs > for 64-bit Intel guests. The "target" of the fix was 32-bit L2s, i.e. I doubt > anything would notice. > > This patch fixes nested migration of 32 bit nested guests, that was > broken because incorrect cached values of SYSENTER msrs were stored in > the migration stream if L1 changed these msrs with > vmload prior to L2 entry. Aha! Finally figured out what this code is doing. KVM intercepts VMLOAD so that KVM can correctly model the VMLOAD behavior of dropping bits 63:32, i.e. to clear svm->sysenter_eip_hi and svm->sysenter_esp_hi. So the code is correct. I'll add this comment: /* * Intercept VMLOAD if the vCPU mode is Intel in order to emulate that * VMLOAD drops bits 63:32 of SYSENTER (ignoring the fact that exposing * SVM on Intel is bonkers and extremely unlikely to work). */