[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 53/66] i386/tdx: Wire TDX_REPORT_FATAL_ERROR with GuestPan
From: |
Markus Armbruster |
Subject: |
Re: [PATCH v4 53/66] i386/tdx: Wire TDX_REPORT_FATAL_ERROR with GuestPanic facility |
Date: |
Tue, 27 Feb 2024 16:42:40 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Xiaoyao Li <xiaoyao.li@intel.com> writes:
> On 2/27/2024 9:09 PM, Markus Armbruster wrote:
> [...]
>>>>>>> @@ -566,6 +569,27 @@
>>>>>>> 'psw-addr': 'uint64',
>>>>>>> 'reason': 'S390CrashReason'}}
>>>>>>>
>>>>>>> +##
>>>>>>> +# @GuestPanicInformationTdx:
>>>>>>> +#
>>>>>>> +# TDX Guest panic information specific to TDX GCHI
>>>>>>> +# TDG.VP.VMCALL<ReportFatalError>.
>>>>>>> +#
>>>>>>> +# @error-code: TD-specific error code
>>>>>>
>>>>>> Where could a user find information on these error codes?
>>>>>
>>>>> TDX GHCI (Guset-host-communication-Interface)spec. It defines all the
>>>>> TDVMCALL leaves.
>>>>>
>>>>> 0: panic;
>>>>> 0x1 - 0xffffffff: reserved.
>>>>
>>>> Would it make sense to add a reference?
>>>
>>> https://cdrdv2.intel.com/v1/dl/getContent/726792
>>
>> URLs have this annoying tendency to rot.
>>
>> What about
>>
>> # @error-code: Error code as defined in "Guest-Hypervisor Communication
>> # Interface (GHCI) Specification for Intel TDX 1.5"
>
> I think it gets mentioned at the beginning of @GuestPanicInformationTdx
>
> TDX Guest panic information specific to TDX GHCI
> TDG.VP.VMCALL<ReportFatalError>.
>
> Do we still to mention it in every single member?
No, I didn't recognize the alphabet soup there as a reference :)
Let me try again:
##
# @GuestPanicInformationTdx:
#
# TDX Guest panic information specific to TDX, as specified in the
# "Guest-Hypervisor Communication Interface (GHCI) Specification",
# section TDG.VP.VMCALL<ReportFatalError>.
#
# @error-code: TD-specific error code
#
[...]
#
# Since: 9.0
##
>>>>>>> +#
>>>>>>> +# @gpa: guest-physical address of a page that contains additional
>>>>>>> +# error data, in forms of zero-terminated string.
>>>>>>
>>>>>> "in the form of a zero-terminated string"
>>>>>
>>>>> fixed.
>>>>>
>>>>>>> +#
>>>>>>> +# @message: Human-readable error message provided by the guest. Not
>>>>>>> +# to be trusted.
>>>>>>
>>>>>> How is this message related to the one pointed to by @gpa?
>>>>>
>>>>> In general, @message contains a brief message of the error. While @gpa
>>>>> (when valid) contains a verbose message.
>>>>>
>>>>> The reason why we need both is because sometime when TD guest hits a
>>>>> fatal error, its memory may get corrupted so we cannot pass information
>>>>> via @gpa. Information in @message is passed through GPRs.
>>>>
>>>> Well, we do pass information via @gpa, always. I guess it page's
>>>> contents can be corrupted.
>>>
>>> No. It's not always. the bit 63 of the error code is "GPA valid" bit.
>>> @gpa is valid only when bit 63 of error code is 1.
>>>
>>> And current Linux TD guest implementation doesn't use @gpa at all.
>>> https://github.com/torvalds/linux/blob/45ec2f5f6ed3ec3a79ba1329ad585497cdcbe663/arch/x86/coco/tdx/tdx.c#L131
>>
>> Aha!
>>
>> Why would we want to include @gpa when the "GPA valid" bit is off?
>>
>> If we do want it, then
>>
>> # @gpa: guest-physical address of a page that contains more verbose
>> # error information, as zero-terminated string. Valid when the
>> # "GPA valid" bit is set in @error-code.
>>
>> If we don't, then make @gpa optional, present when valid, and document
>> it like this:
>>
>> # @gpa: guest-physical address of a page that contains more verbose
>> # error information, as zero-terminated string. Present when the
>> # "GPA valid" bit is set in @error-code.
>
> I will go this direction.
>
> thanks!
You're welcome!
[...]