- Recording and slides uploaded[1]. - Hold off on v20 for a few weeks, to try and land as much prep work as possible before v20. - Exactly how to slice n' dice the series to make it easier to review is TBD, but generally speaking the plan is to queue patches into a "dead" branch, e.g. kvm/kvm-coco-queue, when they are ready, to reduce the sheer volume of the series and thus help alleviate reviewer fatigue. - Don't hardcode fixed/required CPUID values in KVM, use available metadata from TDX Module to reject "bad" guest CPUID (or let the TDX module reject?). I.e. don't let a guest silently run with a CPUID that diverges from what userspace provided. - Ideally, the TDX Module would come with full metadata (not in JSON format) that KVM can (a) use to reject a "bad" CPUID configuration (from userspace), and (b) that KVM can provide to userspace to make debugging issues suck less. - For guest MAXPHYADDR vs. GPAW, rely on KVM_GET_SUPPORTED_CPUID to enumerate the usable MAXPHYADDR[2], and simply refuse to enable TDX if the TDX Module isn't compatible. Specifically, if MAXPHYADDR=52, 5-level paging is enabled, but the TDX-Module only allows GPAW=0, i.e. only supports 4-level paging. [1] https://drive.google.com/corp/drive/folders/1hm_ITeuB6DjT7dNd-6Ezybio4tRRQOlC [2] https://lore.kernel.org/all/20240313125844.912415-1-kraxel@xxxxxxxxxx
