On Thu, 2024-03-28 at 22:45 +0800, Xiaoyao Li wrote: > I don't argue it makes any difference to guest. I argue that it is a bad > design of TDX to make MTRR fixed1, which leaves the tough problem to > VMM. TDX architecture is one should be blamed. I didn't see anyone arguing against this point. It does seems strange to force something to be exposed that can't be fully handled. I wonder what the history is. > > Though TDX is going to change it, we have to come up something to handle > with current existing TDX if we want to support them. Right. The things being discussed are untenable as long term solutions. The question is, is there anything acceptable in the meantime. That is the goal of this thread. We do have the other option of waiting for a new TDX module that could fix it better, but I thought exiting to userspace for the time being would be way to move forward. Would be great to have a maintainer chime in on this point. > > I have no objection of leaving it to userspace, via KVM_EXIT_TDX_VMCALL. > If we go this path, I would suggest return error to TD guest on QEMU > side (when I prepare the QEMU patch for it) because QEMU cannot emulate > it neither. It would be nice to give the user (user of qemu) some sort of notice of what was going on. For Linux the workaround is clearcpuid=mtrr. If qemu can print something like "MTRRs not supported", or I don't know what message fits. Then the user can see what the problem is and add that to the kernel command line. If they just see a guest crash because it can't handle the error, they will have to debug.
