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 531B9CCA479 for ; Tue, 28 Jun 2022 16:02:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348207AbiF1QCk (ORCPT ); Tue, 28 Jun 2022 12:02:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348263AbiF1QCM (ORCPT ); Tue, 28 Jun 2022 12:02:12 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id ACBD135DE0 for ; Tue, 28 Jun 2022 09:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656432099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JGJSJfbr5IZYXtadU3vbyg4xqHn1JyJrxNS5REcEGD0=; b=OTrdEIsnwmsyrkBLMzblvVxGjX9l3mAE/cSuO7NbTRzEzSipgYoobboTF4qjDYUYnTACYw ZXnZzgDsgcYSa4BCR2d+8Goa3om+nMya1jEyUB/txj1+yvb7T5whe6jjg72e5A2rNyOuJL +b9BhukeLalOJmkTKnXj4LHte0wcJg0= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-618-z42dDYIBPnKnOz3u_SHQFA-1; Tue, 28 Jun 2022 12:01:38 -0400 X-MC-Unique: z42dDYIBPnKnOz3u_SHQFA-1 Received: by mail-wm1-f72.google.com with SMTP id l17-20020a05600c4f1100b0039c860db521so7289167wmq.5 for ; Tue, 28 Jun 2022 09:01:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=JGJSJfbr5IZYXtadU3vbyg4xqHn1JyJrxNS5REcEGD0=; b=OH6GgnFGGCLsfuQ7M7BJDJ3zScebBW+S5uOz0vhB0JyQNgT95jF6ZB0xWDWpnrP/Vi UrpU9UC/GuWAR8U95poA06Y7szBJikN1+BnCzrj3cituzvsd7LvP6sozGj67SX3Zqrlg X05sMWyl9qUVeH2LLXcb6BvHMKvQvm5usKoKEEmgngjx6FIAHRIeMqhGl2OY6j1NLIW9 uHOaVodOotI9Yt+0A/gIAsAiMhhyocrpiLIxk2jzDfixerPAwwJTHuBZYuuzjdIc7I7b z3OcIAzFJdUq0Rg17oGiS+1IwToK2fbdtPu+ul2PcBDkj/r9i5/r2VSpSF0NM2IZPMR4 Z+XQ== X-Gm-Message-State: AJIora+hKBLokVVwG16hBIeyd1D0xeTrnQp+4FK+41NRBcgdUUMbCa4B MWm2y4r6+VGvHeasCLH/ROejkOOQexCgAidUG4UtJpKTzUCNhGHivhCkB+iDe6erkMUuYLihg9q 5/pbsOxSMoAuJtjKrm8HtOjkejuUPjgh1Y5Qrchzyxrpu+noq8a14vEkWxXPvIEhHgsXmQIe/Op XH X-Received: by 2002:a05:6000:1f81:b0:21b:a1b5:776 with SMTP id bw1-20020a0560001f8100b0021ba1b50776mr17518006wrb.201.1656432096941; Tue, 28 Jun 2022 09:01:36 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sA2iKj4+d2oyW9nuIAY6VibtPWKOXWK1EHitza3iry3e5bn2dFQxdxpa4VzAIODzGDvB5VAQ== X-Received: by 2002:a05:6000:1f81:b0:21b:a1b5:776 with SMTP id bw1-20020a0560001f8100b0021ba1b50776mr17517967wrb.201.1656432096618; Tue, 28 Jun 2022 09:01:36 -0700 (PDT) Received: from fedora (nat-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id i8-20020a5d5588000000b002102f2fac37sm14097073wrv.51.2022.06.28.09.01.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jun 2022 09:01:35 -0700 (PDT) From: Vitaly Kuznetsov To: Jim Mattson , Sean Christopherson , Paolo Bonzini , Anirudh Rayabharam Cc: kvm@vger.kernel.org, Wanpeng Li , Maxim Levitsky , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/14] KVM: nVMX: Use vmcs_config for setting up nested VMX MSRs In-Reply-To: References: <20220627160440.31857-1-vkuznets@redhat.com> <87y1xgubot.fsf@redhat.com> Date: Tue, 28 Jun 2022 18:01:34 +0200 Message-ID: <87letgu68x.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jim Mattson writes: > On Tue, Jun 28, 2022 at 7:04 AM Vitaly Kuznetsov wrote: >> ... >> Jim Mattson writes: >> >> > Just checking that this doesn't introduce any backwards-compatibility >> > issues. That is, all features that were reported as being available in >> > the past should still be available moving forward. >> > >> >> All the controls nested_vmx_setup_ctls_msrs() set are in the newly >> introduced KVM_REQ_VMX_*/KVM_OPT_VMX_* sets so we should be good here >> (unless I screwed up, of course). >> >> There's going to be some changes though. E.g this series was started by >> Anirudh's report when KVM was exposing SECONDARY_EXEC_TSC_SCALING while >> running on KVM and using eVMCS which doesn't support the control. This >> is a bug and I don't think we need and 'bug compatibility' here. > > You cannot force VM termination on a kernel upgrade. On live migration > from an older kernel, the new kernel must be willing to accept the > suspended state of a VM that was running under the older kernel. In > particular, the new KVM_SET_MSRS must accept the values of the VMX > capability MSRS that userspace obtains from the older KVM_GET_MSRS. I > don't know if this is what you are referring to as "bug > compatibility," but if it is, then we absolutely do need it. > Oh, right you are, we do seem to have a problem. Even for eVMCS case, the fact that we expose a feature which can't be used in VMX control MSRs doesn't mean that the VM is broken. In particular, the VM may not be using VMX features at all. Same goes to PERF_GLOBAL_CTRL errata. vmx_restore_control_msr() currenly does strict checking of the supplied data against what was initially set by nested_vmx_setup_ctls_msrs(), this basically means we cannot drop feature bits, just add them. Out of top of my head I don't see a solution other than relaxing the check by introducing a "revoke list"... Another questions is whether we want guest visible MSR value to remain like it was before migration or we can be brave and clear 'broken' feature bits there (the features are 'broken' so they couldn't be in use, right?). I'm not sure. Anirudh, the same concern applies to your 'intermediate' patch too. Smart ideas on what can be done are more than welcome) -- Vitaly