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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 740D0C4345F for ; Mon, 22 Apr 2024 21:24:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04C276B0082; Mon, 22 Apr 2024 17:24:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3E526B008C; Mon, 22 Apr 2024 17:24:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E06906B0092; Mon, 22 Apr 2024 17:24:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BF84F6B0082 for ; Mon, 22 Apr 2024 17:24:01 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6EA821402C0 for ; Mon, 22 Apr 2024 21:24:01 +0000 (UTC) X-FDA: 82038445482.03.5F7493F Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) by imf06.hostedemail.com (Postfix) with ESMTP id AB98418001D for ; Mon, 22 Apr 2024 21:23:59 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=VV0LfSUR; spf=pass (imf06.hostedemail.com: domain of 3btUmZgYKCOsfRNaWPTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--seanjc.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3btUmZgYKCOsfRNaWPTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713821039; h=from:from:sender: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:dkim-signature; bh=5uVx/t9/onkYc8i256VPb5hdTG5OQAkMTur1j7RQo/Y=; b=zbQMy3BBEzJYcFOdG/uaWpHy19S6yWhEpWqon8pSZxMP3LO+0Kh5HYXc735IiC3eclC+ws KLzPASFqcacSNIpGkQ4ni/h/I51iunoqfBr0B1onZq6G8qn4bET9Pcu/FKWSU3aNcNODCp RPjZHKeXHg+27YfRkLTXycQgWq+qCss= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=VV0LfSUR; spf=pass (imf06.hostedemail.com: domain of 3btUmZgYKCOsfRNaWPTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--seanjc.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3btUmZgYKCOsfRNaWPTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713821039; a=rsa-sha256; cv=none; b=eHhJyh56Gxo/R23ksBt7L5q2N+1ywVzieCetxoDkL4/5xXcfmv0/5Ot4dwia0p9pLZFCvo ySmTOgsazSnH9DTggQtmwl2j65pzRvUw7X+nT4qiVwHLvJgp857hDpg/Gmi5Qwfyd7VUO5 QBj5xlcPgAKZXKcwDcQwrtrZA4ceyMU= Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-618891b439eso80775107b3.3 for ; Mon, 22 Apr 2024 14:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713821039; x=1714425839; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=5uVx/t9/onkYc8i256VPb5hdTG5OQAkMTur1j7RQo/Y=; b=VV0LfSURLS91gJKvSIUYjw5Eehg0AKIVGWx8fRQRUZh0k9v9Vzjor3nWYdyft04VUN tZl/qaZcXXAVbb/CVmAzVOrEJn1xf3k+EztmSYzO1FbH6hXVOPE3wB1C+WFqeJ2bJ+Wa Xh46Gq0ZrjXfhhVAaEzQO10/tbhqOR4fMAk6KpmlMlSV3E009SRYaiW8833GpQ3CYkPX 5iAiFZ2+j9lGjJB2h5G8tfMZVro3ogISdgaWc/dAkcl8MBoHRlzkCi9o+kted2cPYDKS npYKjST17mtuQiJgEWLKAaIHWUg31TuVpyzn1Fdyv346xU5xwG8ziI/PaPr2vVn3USi6 goRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713821039; x=1714425839; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5uVx/t9/onkYc8i256VPb5hdTG5OQAkMTur1j7RQo/Y=; b=wrdeEzFgo1PYWepm/0OsUsy44jvi+kmARRz6qaGMQm2anxF6hGb1GXG0BmyQsmF33A Orq0W2HLCEiNerFyCcoTQPOIOo+Ia9Ncosewkqb6D+L+kglFlMes94u/uMu0ClSE3rFP W+Z+1Oig1WOvNR3bZp4q3zCNGp3Ef/3wPx/Nv+8rK+U1DPhPoat94h3N5lsdlyz0S5ia n+6xmErDPQZRSI1K7feYhE3Fdj8eXV6zekzcrn2oB8dHbnN3274H9ktNF44RSmHU3why /KEcqra7kOZzO+wxSw9AEwywoaCL2jW1vjpFV/6mUNISSEr6jiYQvG0sEdBhO0LrUNXi fwzw== X-Forwarded-Encrypted: i=1; AJvYcCUO7I2R1oz/EEw1Ic/+IqsbgZ9SuQcxBW7XdjNIHo3b0eNYW3Q9UcimtCkBGUgeC7Px/JnmiePd7LXYXQW1ivfENTA= X-Gm-Message-State: AOJu0YyvVJToz8ta4mUbiKeXz/Gvb/o/ZnuTobcZ2gt0kh7u1e1C2EkQ a+TapSFe4wUVdlBHTSP3kjNJDfv9j8xR7UHmEhoeESGpMdYOIakzIAUbItC6AWbC6IfoAzvAeaH uZA== X-Google-Smtp-Source: AGHT+IFB76IZsBj/WkAnr4URUhjuMUZMHRKzmaQ2M773fcwMt+w+XUH9UmMi/TJMMkVL4AKbrxpXlaHYu+U= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:13:b0:61b:3a8:3360 with SMTP id bc19-20020a05690c001300b0061b03a83360mr2745903ywb.1.1713821038654; Mon, 22 Apr 2024 14:23:58 -0700 (PDT) Date: Mon, 22 Apr 2024 14:23:57 -0700 In-Reply-To: Mime-Version: 1.0 References: Message-ID: Subject: Re: [RFC PATCH v5 09/29] KVM: selftests: TDX: Add report_fatal_error test From: Sean Christopherson To: Yan Zhao Cc: Ackerley Tng , sagis@google.com, linux-kselftest@vger.kernel.org, afranji@google.com, erdemaktas@google.com, isaku.yamahata@intel.com, pbonzini@redhat.com, shuah@kernel.org, pgonda@google.com, haibo1.xu@intel.com, chao.p.peng@linux.intel.com, vannapurve@google.com, runanwang@google.com, vipinsh@google.com, jmattson@google.com, dmatlack@google.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="us-ascii" X-Stat-Signature: nrucibh5kudjn1jpanc77bfqtnyx8nyt X-Rspamd-Queue-Id: AB98418001D X-Rspamd-Server: rspam02 X-Rspam-User: X-HE-Tag: 1713821039-655582 X-HE-Meta: U2FsdGVkX1/bM5f+tfK97PS9KMMVVyWMQMsor5glvTvPvCRYhy29ZeN1dhckbexuzl3RQ0UaXvs7xyJmKanZeL+/7aJVSpgocC2U2NerfPYbqjqJqFTZ15J2VRC2YQwVkZZZiXDu7KNLHVOUa1/DaRoCZCeOtpECpZW/zs0YviKalJSpSUBMdj1OyOvn2v2YuBcAvKCj+yu32FtnM1aunQnfleQYAuY5FhU1FVqOp8O74Ygq2l837b3CxI2YtMYqFdGOcxhtvl+6HcoPPxVd2TFiHHqNnrD2xFhoKxOy8IqMOdL+3f8D0Z7B7wSkZun3tXSBaAa5yNbYKpuxe/1jqTTp5800KKwV7kEySwNIZSADuNeSi6xniJQHUjBp77nn6zxYmy81TPPmjT0v6j1Gci8oyLglFUuHNg0Kx/cL3KvdycUQgiywAa48h9/aJTKZivIbWl644rDSBbibw1NlxhAGwbC50pv7JfTYapiA9Qyz1fZVy3w+kqsmlI2Btx0ptJPEE/2ZMhU3k4xR2FVraG9Fd4VM+M16rK8T/OlfTJbVB5vSp6PjmCXCTzUFRfv/6Zww/xP1+SpDVX1KC30T07a7LxwqY9tBMBHaYWbUzjgSnsW9Qh6v/sk6HAVoW3SWoW869oyH76Ed8P31fJQUm3xPWb0UYa8MmZLIfaLFYmZK/7Tb6yJWStDIbCgmAHAtHvlyAjWF3HK7BkvQljj3xCbCjwlr7caxLXzDsUHiRLRfvpnjD83jEc8oceANXJr35goVFUuqHzZlv+VoOSbTn5XXcNg8u6C2s1GXg5YKDpQ3W9sg7Z8xvQQ0h8GQWyzu8iyqbI9kltGNh8Ci2xaHuK79TJr6FZRr7sakAjtLbcU/kXoqgOqTVKAINODzVci0ef3MNLfsj7wtZH3Lxiq7ENQk89vOw5iMcf/gS5wjDvUe9NiPwLlgSx4kXkvoCfuLs+mm3wOEmVvqjJ3cUv7 YclKKeUa qv/9RhdkcLZtlmRjm84So2YKCkQTvC7+VT/lWfhwdTSyzuRj1wQiuBBoR5zc68BTghL22RWNYGT3GxiGRbPKWtC5FWDrtFrRz7kWE+CKdMT8QLg3g2M+C9jW5rOmuXQapM77PnJDVdVX0c6X+PnQ+7rTNdkbLNu9mRRkCdhNsfN7pQGOmQDDr/BmVX7hACbGXzBRD5c+JYrxUh6jZt/5Pwjfkyy4DzjTQMZpLlWFD4V/Zn3uZA9wYoiBhY3FUXkkmlxW3gtRMo5CGQxQ1YCkOl5ltsZl7v+28pJ7vBViX0ozzkoy+2DMXtJgY7+y6NNO1i1bj0BrSN0W0qLn4c1hcmBt42iWZ5bF0Ihx9ebRUxIefO3nMBeEI3+9gW5tMdL1Crwi940Wc7RDR5d3zOQcPyJqbDbTkYOXIBmcVFlgDq/jMRv29/ugBp6fXOPwb+63VGoIg1YFQKq6jES02YQZ7jvOa2m7I4CKX9op/8dKhSyUqNyEaNevIpZMM7FctjuJjaVzHMSv5jRmMR2sRaubHTIOnrBKGX4pXf22PX1DomobtNrweqoHK8qJ2Hv1e33YYMChu+tPzWi+dEZkHEA6ho0tycrd2KFdwr7ZXmIDf9ay0Kgej5sxi3rZYTbIxOLlVjfEUxdWfyggQF1xvswvln7hrhAYwNCqTtI0hIXiBOHPxtEJXPya+m5qMTyoItLpd+SyOMIR0XQPJEzN2xR+900UJtBZjD6H9xUYYUZCBl9FvSU4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.021787, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Apr 18, 2024, Yan Zhao wrote: > On Tue, Apr 16, 2024 at 11:50:19AM -0700, Sean Christopherson wrote: > > On Mon, Apr 15, 2024, Yan Zhao wrote: > > > On Mon, Apr 15, 2024 at 08:05:49AM +0000, Ackerley Tng wrote: > > > > >> The Intel GHCI Spec says in R12, bit 63 is set if the GPA is valid. As a > > > > > But above "__LINE__" is obviously not a valid GPA. > > > > > > > > > > Do you think it's better to check "data_gpa" is with shared bit on and > > > > > aligned in 4K before setting bit 63? > > > > > > > > > > > > > I read "valid" in the spec to mean that the value in R13 "should be > > > > considered as useful" or "should be passed on to the host VMM via the > > > > TDX module", and not so much as in "validated". > > > > > > > > We could validate the data_gpa as you suggested to check alignment and > > > > shared bit, but perhaps that could be a higher-level function that calls > > > > tdg_vp_vmcall_report_fatal_error()? > > > > > > > > If it helps, shall we rename "data_gpa" to "data" for this lower-level, > > > > generic helper function and remove these two lines > > > > > > > > if (data_gpa) > > > > error_code |= 0x8000000000000000; > > > > > > > > A higher-level function could perhaps do the validation as you suggested > > > > and then set bit 63. > > > This could be all right. But I'm not sure if it would be a burden for > > > higher-level function to set bit 63 which is of GHCI details. > > > > > > What about adding another "data_gpa_valid" parameter and then test > > > "data_gpa_valid" rather than test "data_gpa" to set bit 63? > > > > Who cares what the GHCI says about validity? The GHCI is a spec for getting > > random guests to play nice with random hosts. Selftests own both, and the goal > > of selftests is to test that KVM (and KVM's dependencies) adhere to their relevant > > specs. And more importantly, KVM is NOT inheriting the GHCI ABI verbatim[*]. > > > > So except for the bits and bobs that *KVM* (or the TDX module) gets involved in, > > just ignore the GHCI (or even deliberately abuse it). To put it differently, use > > selftests verify *KVM's* ABI and functionality. > > > > As it pertains to this thread, while I haven't looked at any of this in detail, > > I'm guessing that whether or not bit 63 is set is a complete "don't care", i.e. > > KVM and the TDX Module should pass it through as-is. > > > > [*] https://lore.kernel.org/all/Zg18ul8Q4PGQMWam@google.com > Ok. It makes sense to KVM_EXIT_TDX. > But what if the TDVMCALL is handled in TDX specific code in kernel in future? > (not possible?) KVM will "handle" ReportFatalError, and will do so before this code lands[*], but I *highly* doubt KVM will ever do anything but forward the information to userspace, e.g. as KVM_SYSTEM_EVENT_CRASH with data[] filled in with the raw register information. > Should guest set bits correctly according to GHCI? No. Selftests exist first and foremost to verify KVM behavior, not to verify firmware behavior. We can and should use selftests to verify that *KVM* doesn't *violate* the GHCI, but that doesn't mean that selftests themselves can't ignore and/or abuse the GCHI, especially since the GHCI definition for ReportFatalError is frankly awful. E.g. the GHCI prescibes actual behavior for R13, but then doesn't say *anything* about what's in the data page. Why!?!?! If the format in the data page is completely undefined, what's the point of restricting R13 to only be allowed to hold a GPA? And the wording is just as awful: The VMM must validate that this GPA has the Shared bit set. In other words, that a shared-mapping is used, and that this is a valid mapping for the TD. I'm pretty sure it's just saying that the TDX module isn't going to verify the operate, i.e. that the VMM needs to protect itself, but it would be so much better to simply state "The TDX Module does not verify this GPA", because saying the VMM "must" do something leads to pointless discussions like this one, where we're debating over whether or *our* VMM should inject an error into *our* guest. Anyways, we should do what makes sense for selftests and ignore the stupidity of the GHCI when doing so yields better code. If that means abusing R13, go for it. If it's a sticking point for anyone, just use one of the "optional" registers. Whatever we do, bury the host and guest side of selftests behind #defines or helpers so that there are at most two pieces of code that care which register holds which piece of information. [*] https://lore.kernel.org/all/20240404230247.GU2444378@ls.amr.corp.intel.com