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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 56E08C433E0 for ; Tue, 12 Jan 2021 12:15:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 159952310D for ; Tue, 12 Jan 2021 12:15:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732449AbhALMOr (ORCPT ); Tue, 12 Jan 2021 07:14:47 -0500 Received: from mail.skyhub.de ([5.9.137.197]:57542 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732455AbhALMOr (ORCPT ); Tue, 12 Jan 2021 07:14:47 -0500 Received: from zn.tnic (p200300ec2f0e8c0026b5c8bc02f060b7.dip0.t-ipconnect.de [IPv6:2003:ec:2f0e:8c00:26b5:c8bc:2f0:60b7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id A5F861EC0472; Tue, 12 Jan 2021 13:14:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1610453645; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=4w8mzi966gYW3Xfnk2BjaCXIPZPykNO5//jfGuwn8bg=; b=W4KSP/np+hFfozdVXNuZ9SJqfFYB6B93B4xH/8lum//CNETvhZ//YuQTDmyUw+aZG1mlYP bR98Kx0uOrjGeIISnlIIX4oXNzdgDyQv0mjR5sxF5pmIccjM9R0fZMG5HfYTTqJRE5l4CA G1+91h/fDHXRplrGgVHye/Tp1LrisUM= Date: Tue, 12 Jan 2021 13:13:59 +0100 From: Borislav Petkov To: Sean Christopherson Cc: Kai Huang , Dave Hansen , linux-sgx@vger.kernel.org, kvm@vger.kernel.org, x86@kernel.org, jarkko@kernel.org, luto@kernel.org, haitao.huang@intel.com, pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com Subject: Re: [RFC PATCH 04/23] x86/cpufeatures: Add SGX1 and SGX2 sub-features Message-ID: <20210112121359.GC13086@zn.tnic> References: <20210107064125.GB14697@zn.tnic> <20210108150018.7a8c2e2fb442c9c68b0aa624@intel.com> <20210108200350.7ba93b8cd19978fe27da74af@intel.com> <20210108071722.GA4042@zn.tnic> <20210109011939.GL4042@zn.tnic> <20210111190901.GG25645@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Mon, Jan 11, 2021 at 11:20:11AM -0800, Sean Christopherson wrote: > Well, mechanically, that would generate a build failure if the kernel does the > obvious things and names the 'enum cpuid_leafs' entry CPUID_12_EAX. That would > be an obvious clue that KVM should be updated. Then we need to properly document that whenever someone does that change, someone needs to touch the proper places. > If the kernel named the enum entry something different, and we botched the code > review, KVM would continue to work, but would unnecessarily copy the bits it > cares about to its own word. E.g. the boot_cpu_has() checks and translation to > __X86_FEATURE_* would still be valid. As far as failure modes go, that's not > terrible. Right, which reminds me: with your prototype patch, we would have: static __always_inline void __kvm_cpu_cap_mask(enum cpuid_leafs leaf) { const struct cpuid_reg cpuid = x86_feature_cpuid(leaf * 32); struct kvm_cpuid_entry2 entry; reverse_cpuid_check(leaf); cpuid_count(cpuid.function, cpuid.index, &entry.eax, &entry.ebx, &entry.ecx, &entry.edx); kvm_cpu_caps[leaf] &= *__cpuid_entry_get_reg(&entry, cpuid.reg); } which does read CPUID from the hw and kvm_cpu_caps[] has already the copied bits from boot_cpu_data.x86_capability. Now you said that reading the CPUID is mostly redundant but we're paranoid so we do it anyway, just in case, so how about we remove the copying of boot_cpu_data.x86_capability? That's one less dependency on the baremetal implementation. Practically, nothing changes for kvm because it will read CPUID which is the canonical thing anyway. And this should simplify the deal more and keep it simple(r). Hmmm. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette