On Mon, May 27, 2024 at 2:26 PM Binbin Wu <binbin.wu@xxxxxxxxxxxxxxx> wrote: > > It seems like TDX should be able to do something similar by limiting the > > size of each KVM_HC_MAP_GPA_RANGE to TDX_MAP_GPA_MAX_LEN, and then > > returning TDG_VP_VMCALL_RETRY to guest if the original size was greater > > than TDX_MAP_GPA_MAX_LEN. But at that point you're effectively done with > > the entire request and can return to guest, so it actually seems a little > > more straightforward than the SNP case above. E.g. TDX has a 1:1 mapping > > between TDG_VP_VMCALL_MAP_GPA and KVM_HC_MAP_GPA_RANGE events. (And even > > similar names :)) > > > > So doesn't seem like there's a good reason to expose any of these > > throttling details to userspace, I think userspace should never be worried about throttling. I would say it's up to the guest to split the GPA into multiple ranges, but that's not how arch/x86/coco/tdx/tdx.c is implemented so instead we can do the split in KVM instead. It can be a module parameter or VM attribute, establishing the size that will be processed in a single TDVMCALL. Paolo > > The reasons I want to put the throttling in userspace are: > 1. Hardcode the TDX_MAP_GPA_MAX_LEN in kernel may not be preferred. > 2. The throttling thing doesn't need to be TDX specific, it can be > generic in userspace. > > I think we can set a reasonable value in userspace, so that for SNP, it > doesn't trigger the throttling since the large request will be split to > multiple userspace requests. > > > > in which case existing > > KVM_HC_MAP_GPA_RANGE interface seems like it should be sufficient. > > > > -Mike > > > >> > >>>> For TDX, it may also want to use KVM_HC_MAP_GPA_RANGE hypercall to > >>>> userspace via KVM_EXIT_HYPERCALL. > >>> Yes, definitely. > >>> > >>> Paolo > >>> >
