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=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 D8856C3A5A5 for ; Thu, 5 Sep 2019 12:46:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CF79822466 for ; Thu, 5 Sep 2019 12:46:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389527AbfIEMqG (ORCPT ); Thu, 5 Sep 2019 08:46:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39412 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731418AbfIEMqF (ORCPT ); Thu, 5 Sep 2019 08:46:05 -0400 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (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 EEE1B81DE3 for ; Thu, 5 Sep 2019 12:46:04 +0000 (UTC) Received: by mail-wm1-f69.google.com with SMTP id v4so393450wmh.9 for ; Thu, 05 Sep 2019 05:46:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=cqNmM0Hwlmyj9h/MG6Wvpgg7kXXsJp+5V5Vxs9mhcqU=; b=UPSjVX0pHRIhCjTIT0VuwnlytQriDTf98gdH974Tc9ycNqz6JZE9CaN75UAyVkLvWU xFdgHclJCHVBjpSkOgZeYP3ywywdYK59ywGgIuwDln9kKmPV6iv7dV/GpY1Q+CQVELy+ LtzdTQnbq3bOvGfuMyv7CTzH9ZBgaK/e2C7I2kQEnoFfwSA98QO0HKnZ+PIYi47vM130 pu2UEzJFrhLbcz7XwkZhVY4aO42n+TmAVfcdd/l/1LI3wo1OF5e2saQeuxvgQM6pBxj8 RsIq/YUS1vGHYqTrn2Q0At3FKG8+ydgWkCfqyN0Pio5LNu2B2gsyWeaWQ6SuTR0ocXx/ 3JKw== X-Gm-Message-State: APjAAAWh/jMn08ka1amt+o1Ruf39IgYU1HAFmBzDM1tlqX89WiJZ9jcb LbYohmh5/r2x1x5+JT9tjMK4KN5k/QOVn4V44gcteva7Nwqs7AuiPrhTftpkkzIgyIuuYud1guG AK87NcViJKtB4 X-Received: by 2002:a1c:4c14:: with SMTP id z20mr2107252wmf.28.1567687563648; Thu, 05 Sep 2019 05:46:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqzgtgVR58GvkPJGffN4yMMmTnq2ROMqNATyP3acVJ3IWAV928JpOT2ZB2k3lytPDOM6Bd3rjA== X-Received: by 2002:a1c:4c14:: with SMTP id z20mr2107237wmf.28.1567687563438; Thu, 05 Sep 2019 05:46:03 -0700 (PDT) Received: from vitty.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id n1sm2673924wrg.67.2019.09.05.05.46.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Sep 2019 05:46:02 -0700 (PDT) From: Vitaly Kuznetsov To: Aaron Lewis Cc: kvm@vger.kernel.org, Janakarajan.Natarajan@amd.com, Jim Mattson Subject: Re: [Patch] KVM: SVM: Fix svm_xsaves_supported In-Reply-To: References: <20190904001422.11809-1-aaronlewis@google.com> <87o900j98f.fsf@vitty.brq.redhat.com> Date: Thu, 05 Sep 2019 14:46:01 +0200 Message-ID: <87lfv2kj1y.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Aaron Lewis writes: > On Wed, Sep 4, 2019 at 9:51 AM Vitaly Kuznetsov wrote: >> >> Aaron Lewis writes: >> >> > AMD allows guests to execute XSAVES/XRSTORS if supported by the host. This is different than Intel as they have an additional control bit that determines if XSAVES/XRSTORS can be used by the guest. Intel also has intercept bits that might prevent the guest from intercepting the instruction as well. AMD has none of that, not even an Intercept mechanism. AMD simply allows XSAVES/XRSTORS to be executed by the guest if also supported by the host. >> > >> >> WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) >> >> > Signed-off-by: Aaron Lewis >> > --- >> > arch/x86/kvm/svm.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c >> > index 1f220a85514f..b681a89f4f7e 100644 >> > --- a/arch/x86/kvm/svm.c >> > +++ b/arch/x86/kvm/svm.c >> > @@ -5985,7 +5985,7 @@ static bool svm_mpx_supported(void) >> > >> > static bool svm_xsaves_supported(void) >> > { >> > - return false; >> > + return boot_cpu_has(X86_FEATURE_XSAVES); >> > } >> > >> > static bool svm_umip_emulated(void) >> >> I had a similar patch in my stash when I tried to debug Hyper-V 2016 >> not being able to boot on KVM. I may have forgotten some important >> details, but if I'm not mistaken XSAVES comes paired with MSR_IA32_XSS >> and some OSes may actually try to write there, in particular I've >> observed Hyper-V 2016 trying to write '0'. Currently, we only support >> MSR_IA32_XSS in vmx code, this will need to be extended to SVM. >> >> Currently, VMX code only supports writing '0' to MSR_IA32_XSS: >> >> case MSR_IA32_XSS: >> if (!vmx_xsaves_supported() || >> (!msr_info->host_initiated && >> !(guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) && >> guest_cpuid_has(vcpu, X86_FEATURE_XSAVES)))) >> return 1; >> /* >> * The only supported bit as of Skylake is bit 8, but >> * it is not supported on KVM. >> */ >> if (data != 0) >> return 1; >> >> >> we will probably need the same limitation for SVM, however, I'd vote for >> creating separate kvm_x86_ops->set_xss() implementations. >> >> -- >> Vitaly > > Fixed the unwrapped description in v2. > > As for extending VMX behavior to SVM for MSR_IA_32_XSS; I will do this > in a follow up patch. Thanks for calling this out. Doing this in a separate patch is fine, however, I think this patch should come before we start announcing XSAVES support on AMD: both MSR_IA_32_XSS and XSAVES/XRSTORS instructions are enumerated by CPUID.(EAX=0DH, ECX=1).EAX[bit 3] so an unprepared guest may try accessing MSR_IA_32_XSS and get #GP. -- Vitaly