From: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Elena Reshetova <elena.reshetova@intel.com>,
x86@kernel.org, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] x86/tdx: Use ReportFatalError to report missing SEPT_VE_DISABLE
Date: Fri, 9 Dec 2022 12:51:07 -0800 [thread overview]
Message-ID: <2e305bb5-9595-3531-6134-24344ff5c797@linux.intel.com> (raw)
In-Reply-To: <20221209170647.r32yjyc3hsqtnffo@box.shutemov.name>
On 12/9/22 9:06 AM, Kirill A. Shutemov wrote:
> On Fri, Dec 09, 2022 at 07:42:56AM -0800, Sathyanarayanan Kuppuswamy wrote:
>>
>>
>> On 12/9/22 5:25 AM, Kirill A. Shutemov wrote:
>>> The check for SEPT_VE_DISABLE happens early in the kernel boot where
>>> earlyprintk is not yet functional. Kernel successfully detect broken
>>> TD configuration and stops the kernel with panic(), but it cannot
>>> communicate the reason to the user.
>>>
>>> Use TDG.VP.VMCALL<ReportFatalError> to report the error. The hypercall
>>> can encode message up to 64 bytes in eight registers.
>>>
>>> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>>> ---
>>> arch/x86/coco/tdx/tdx.c | 38 +++++++++++++++++++++++++++++++++++++-
>>> 1 file changed, 37 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
>>> index cfd4c95b9f04..8ad04d101270 100644
>>> --- a/arch/x86/coco/tdx/tdx.c
>>> +++ b/arch/x86/coco/tdx/tdx.c
>>> @@ -22,6 +22,7 @@
>>>
>>> /* TDX hypercall Leaf IDs */
>>> #define TDVMCALL_MAP_GPA 0x10001
>>> +#define TDVMCALL_REPORT_FATAL_ERROR 0x10003
>>>
>>> /* MMIO direction */
>>> #define EPT_READ 0
>>> @@ -140,6 +141,41 @@ int tdx_mcall_get_report0(u8 *reportdata, u8 *tdreport)
>>> }
>>> EXPORT_SYMBOL_GPL(tdx_mcall_get_report0);
>>>
>>> +static void __noreturn tdx_panic(const char *msg)
>>> +{
>>> + struct tdx_hypercall_args args = {
>>> + .r10 = TDX_HYPERCALL_STANDARD,
>>> + .r11 = TDVMCALL_REPORT_FATAL_ERROR,
>>> + .r12 = 0, /* Error code: 0 is Panic */
>>> + };
>>> + union {
>>> + /* Define register order according to the GHCI */
>>> + struct { u64 r14, r15, rbx, rdi, rsi, r8, r9, rdx; };
>>> +
>>> + char str[64];
>>> + } message;
>>> +
>>> + /* VMM assumes '\0' in byte 65, if the message took all 64 bytes */
>>> + strncpy(message.str, msg, 64);
>>> +
>>> + args.r8 = message.r8;
>>> + args.r9 = message.r9;
>>> + args.r14 = message.r14;
>>> + args.r15 = message.r15;
>>> + args.rdi = message.rdi;
>>> + args.rsi = message.rsi;
>>> + args.rbx = message.rbx;
>>> + args.rdx = message.rdx;
>>> +
>>> + /*
>>> + * Keep calling the hypercall in case VMM did not terminated
>>> + * the TD as it must.
>>> + */
>>> + while (1) {
>>> + __tdx_hypercall(&args, 0);
>>> + }
>>
>> Instead of an infinite loop, I'm wondering if the guest should panic after
>> retrying for few times.
>
> Hm. What difference would it make?
IIUC, the goal of this patch is to report the fatal error to VMM and panic.
But, if VMM does not terminate the guest as we expect, rather than trying
continuously, isn't it better to panic ourselves? That way the behavior
will be similar to what we have currently.
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
next prev parent reply other threads:[~2022-12-09 20:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 13:25 [PATCH 0/4] x86/tdx: Changes for TDX guest initialization Kirill A. Shutemov
2022-12-09 13:25 ` [PATCH 1/4] x86/tdx: Expand __tdx_hypercall() to handle more arguments Kirill A. Shutemov
2022-12-13 22:44 ` Dave Hansen
2022-12-09 13:25 ` [PATCH 2/4] x86/tdx: Use ReportFatalError to report missing SEPT_VE_DISABLE Kirill A. Shutemov
2022-12-09 15:42 ` Sathyanarayanan Kuppuswamy
2022-12-09 17:06 ` Kirill A. Shutemov
2022-12-09 20:51 ` Sathyanarayanan Kuppuswamy [this message]
2022-12-12 16:10 ` Dave Hansen
2022-12-12 16:37 ` Sathyanarayanan Kuppuswamy
2022-12-12 16:39 ` Dave Hansen
2022-12-13 23:06 ` Dave Hansen
2022-12-15 17:12 ` Kirill A. Shutemov
2022-12-15 18:18 ` Dave Hansen
2022-12-15 18:51 ` Kirill A. Shutemov
2022-12-15 21:09 ` Dave Hansen
2022-12-16 2:38 ` Kirill A. Shutemov
2022-12-16 15:22 ` Reshetova, Elena
2022-12-09 13:25 ` [PATCH 3/4] x86/tdx: Relax SEPT_VE_DISABLE check for debug TD Kirill A. Shutemov
2022-12-09 15:45 ` Sathyanarayanan Kuppuswamy
2022-12-09 17:08 ` Kirill A. Shutemov
2022-12-13 23:13 ` Dave Hansen
2022-12-15 15:40 ` Kirill A. Shutemov
2022-12-09 13:25 ` [PATCH 4/4] x86/tdx: Disable NOTIFY_ENABLES Kirill A. Shutemov
2022-12-09 15:50 ` Sathyanarayanan Kuppuswamy
2022-12-09 17:10 ` Kirill A. Shutemov
2022-12-13 23:17 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2e305bb5-9595-3531-6134-24344ff5c797@linux.intel.com \
--to=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=elena.reshetova@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).