Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp5399404pxb; Mon, 7 Feb 2022 00:47:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJyoDKjd5sMkYR+BWqbNVsFdS4u9MSfgs9omxCJ/x2rKiMXQNuKcfNdzifo0khzdC/F5tcps X-Received: by 2002:a05:6402:5cb:: with SMTP id n11mr12895810edx.399.1644223642382; Mon, 07 Feb 2022 00:47:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644223642; cv=none; d=google.com; s=arc-20160816; b=YY4IzkTzKdajI3XkkRW45M34oSWAvjH2fwxbiAeFJCQwd78U9Rcis7fakUsUszNMpz R88vVybq99o5Z9gvNWErmEBNHK5AaoNH7iS0R+v1ilFyEiao1D+l5EsYCLe/DqWmtf0i 9tDU7kCho21JWO6efGk5crdl5/EEA7a8i/HiHflNF9+DC1Gz0hUF8d04A9FWRV+QSbPC qRYOH82T7V3cvvK2/la/iEwpsw+EwERJRgHHubcNZaDXSibfoH8ZxeGC/RdgDBpaWYbK f3PptHAj3Me5ujOfT4MbPW8BLK1vdic/ztHbcnLF4MzI+FT5QG3t5m+v8rPdov+bxXz1 /Rqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=uZ7YbZrJGPMPUOZHBNRpUaCuf4fbjJb2e0v1A635574=; b=ZWc8cV/v/4msXPQI7B3LBczK1k1YrqRORPBbeFmYwKENyA3YqnhtY4M9b/gu//Qdgi nGqqQpyCt8zonl662O/RyGP8IF0K6WYhks4o14lEAao228lqAMomFY7229zxjl1JgKsv jjkhRYwdl7kjOF602MClJMLbyKYhUhuXW70NRPa7EA7C3kR8hdNL/xsgYw7yY6UB/jwL dIUKnP+jgdOSnKZrSyRhfzUU5LLNXZdGKjvoeu5ktmCWHXAcGpM6mA9K41rDmbVwx3Mm reCoF0vKkmVyHMVmqzP766jIhMBb2hKcW4R/tDDa1esva0//5UlSuTIVJ8FUqT6O2c9m fayA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=Wi4j4RdB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z15si3555807edl.518.2022.02.07.00.46.57; Mon, 07 Feb 2022 00:47:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=Wi4j4RdB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238987AbiBEKyO (ORCPT + 99 others); Sat, 5 Feb 2022 05:54:14 -0500 Received: from mail.skyhub.de ([5.9.137.197]:53540 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230020AbiBEKyL (ORCPT ); Sat, 5 Feb 2022 05:54:11 -0500 Received: from zn.tnic (dslb-088-067-221-104.088.067.pools.vodafone-ip.de [88.67.221.104]) (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 E27091EC02DD; Sat, 5 Feb 2022 11:54:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1644058446; 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=uZ7YbZrJGPMPUOZHBNRpUaCuf4fbjJb2e0v1A635574=; b=Wi4j4RdBU/nduEspCZ+AEnQggLzEGh95jTHEMmr+DClFcPOZ5VKO1AVl1fq1d6uEZnyIR9 94WXRdpFGpUC7ZltmJ5nyNtLaG7ckLTwcARlP7XhLQJFPS3GpUVCjl56uVAd6DMN/r7f/0 HzQGDF4BaAeJsfhozkPmEQqp4+mkgvI= Date: Sat, 5 Feb 2022 11:54:01 +0100 From: Borislav Petkov To: Brijesh Singh Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , "Dr . David Alan Gilbert" , brijesh.ksingh@gmail.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH v9 31/43] x86/compressed/64: Add support for SEV-SNP CPUID table in #VC handlers Message-ID: References: <20220128171804.569796-1-brijesh.singh@amd.com> <20220128171804.569796-32-brijesh.singh@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220128171804.569796-32-brijesh.singh@amd.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 28, 2022 at 11:17:52AM -0600, Brijesh Singh wrote: > +/* > + * Individual entries of the SEV-SNP CPUID table, as defined by the SEV-SNP > + * Firmware ABI, Revision 0.9, Section 7.1, Table 14. > + */ > +struct snp_cpuid_fn { > + u32 eax_in; > + u32 ecx_in; > + u64 xcr0_in; > + u64 xss_in; So what's the end result here: -+ u64 __unused; -+ u64 __unused2; ++ u64 xcr0_in; ++ u64 xss_in; those are not unused fields anymore but xcr0 and xss input values? Looking at the FW abi doc, they're only mentioned in "Table 14. CPUID_FUNCTION Structure" that they're XCR0 and XSS at the time of the CPUID execution. But those values are input values to what exactly, guest or firmware? There's a typo in the FW doc, btw: "The guest constructs an MSG_CPUID_REQ message as defined in Table 13. This message contains an array of CPUID function structures as defined in Table 13." That second "Table" is 14 not 13. So, if an array CPUID_FUNCTION[] is passed as part of an MSG_CPUID_REQ command, then, the two _IN variables contain what the guest received from the HV for XCR0 and XSS values. Which means, this is the guest asking the FW whether those values the HV gave the guest are kosher. Am I close? > +static const struct snp_cpuid_info *snp_cpuid_info_get_ptr(void) > +{ > + void *ptr; > + > + asm ("lea cpuid_info_copy(%%rip), %0" > + : "=r" (ptr) Same question as the last time: Why not "=g" and let the compiler decide? > + : "p" (&cpuid_info_copy)); > + > + return ptr; > +} ... > +static bool snp_cpuid_check_range(u32 func) > +{ > + if (func <= cpuid_std_range_max || > + (func >= 0x40000000 && func <= cpuid_hyp_range_max) || > + (func >= 0x80000000 && func <= cpuid_ext_range_max)) > + return true; > + > + return false; > +} > + > +static int snp_cpuid_postprocess(u32 func, u32 subfunc, u32 *eax, u32 *ebx, > + u32 *ecx, u32 *edx) And again, same question as the last time: I'm wondering if you could make everything a lot easier by doing static int snp_cpuid_postprocess(struct cpuid_leaf *leaf) and marshall around that struct cpuid_leaf which contains func, subfunc, e[abcd]x instead of dealing with 6 parameters. Callers of snp_cpuid() can simply allocate it on their stack and hand it in and it is all in sev-shared.c so nicely self-contained... Ok I'm ignoring this patch for now and I'll review it only after you've worked in all comments from the previous review. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette