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;
Message-ID: <51b6613d-eabd-941d-19b2-95b33ec27e99@intel.com>
Date:   Thu, 24 Feb 2022 11:04:04 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Content-Language: en-US
To:     "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        luto@kernel.org, peterz@infradead.org
Cc:     sathyanarayanan.kuppuswamy@linux.intel.com, aarcange@redhat.com,
        ak@linux.intel.com, dan.j.williams@intel.com, david@redhat.com,
        hpa@zytor.com, jgross@suse.com, jmattson@google.com,
        joro@8bytes.org, jpoimboe@redhat.com, knsathya@kernel.org,
        pbonzini@redhat.com, sdeep@vmware.com, seanjc@google.com,
        tony.luck@intel.com, vkuznets@redhat.com, wanpengli@tencent.com,
        thomas.lendacky@amd.com, brijesh.singh@amd.com, x86@kernel.org,
        linux-kernel@vger.kernel.org
References: <20220224155630.52734-1-kirill.shutemov@linux.intel.com>
 <20220224155630.52734-11-kirill.shutemov@linux.intel.com>
From:   Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCHv4 10/30] x86/tdx: Handle CPUID via #VE
In-Reply-To: <20220224155630.52734-11-kirill.shutemov@linux.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2/24/22 07:56, Kirill A. Shutemov wrote:
>  static bool virt_exception_user(struct pt_regs *regs, struct ve_info *ve)
>  {
> -	pr_warn("Unexpected #VE: %lld\n", ve->exit_reason);
> -	return false;
> +	switch (ve->exit_reason) {
> +	case EXIT_REASON_CPUID:
> +		return handle_cpuid(regs);
> +	default:
> +		pr_warn("Unexpected #VE: %lld\n", ve->exit_reason);
> +		return false;
> +	}
>  }

What does this mean for userspace?  What kinds of things are we ceding
to the (untrusted) VMM to supply to userspace?

>  /* Handle the kernel #VE */
> @@ -200,6 +235,8 @@ static bool virt_exception_kernel(struct pt_regs *regs, struct ve_info *ve)
>  		return read_msr(regs);
>  	case EXIT_REASON_MSR_WRITE:
>  		return write_msr(regs);
> +	case EXIT_REASON_CPUID:
> +		return handle_cpuid(regs);
>  	default:
>  		pr_warn("Unexpected #VE: %lld\n", ve->exit_reason);
>  		return false;
What kinds of random CPUID uses in the kernel at runtime need this
handling?  Is it really OK that we let the VMM inject arbitrary CPUID
values into random CPUID uses in the kernel... silently?

Is this better than just returning 0's, for instance?