Xiaoyao Li <xiaoyao.li@xxxxxxxxx> 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! [...]
