On 3/14/23 10:16, Isaku Yamahata wrote: >>> TDX 1.5 spec introduced TDX_RND_NO_ENTROPY status code. For TDX 1.0, let's >>> postpone it to TDX 1.5 activity. >> What the heck does this mean? >> >> I don't remember seeing any code here that checks for "TDX 1.0" or "TDX >> 1.5". That means that this code needs to work with _any_ TDX version. >> >> Are features being added to new versions that break code written for old >> versions? > No new feature, but new error code. TDX_RND_NO_ENTROPY, lack of entropy. > For TDX 1.0, some APIs return TDX_SYS_BUSY. It can be contention(lock failure) > or the lack of entropy. The caller can't distinguish them. > For TDX 1.5, they return TDX_RND_NO_ENTROPY instead of TDX_SYS_BUSY in the case > of rdrand/rdseed failure. > > Because both TDX_SYS_BUSY and TDX_RND_NO_ENTROPY are recoverable error > (bit 63 error=1, bit 62 non_recoverable=0), the caller can check error bit and > non_recoverable bit for retry. Oh, that's actually really nice. It separates out the "RDRAND is empty" issue from the "the VMM should have had a lock here" issue. For now, let's consider TDX_SYS_BUSY to basically indicate a non-fatal kernel bug: the kernel called TDX in a way that it shouldn't have. We'll treat it in the kernel as non-recoverable. We'll return an error, WARN_ON(), and keep on running. A follow-on patch can add generic TDX_RND_NO_ENTROPY retry support to the seamcall infrastructure.
