On Thu, Apr 07, 2022 at 09:17:51AM +0800, Xiaoyao Li <xiaoyao.li@xxxxxxxxx> wrote: > On 4/7/2022 9:07 AM, Kai Huang wrote: > > On Wed, 2022-04-06 at 09:54 +0800, Xiaoyao Li wrote: > > > On 4/5/2022 8:52 PM, Paolo Bonzini wrote: > > > > On 3/4/22 20:48, isaku.yamahata@xxxxxxxxx wrote: > > > > > Implement a VM-scoped subcomment to get system-wide parameters. Although > > > > > this is system-wide parameters not per-VM, this subcomand is VM-scoped > > > > > because > > > > > - Device model needs TDX system-wide parameters after creating KVM VM. > > > > > - This subcommands requires to initialize TDX module. For lazy > > > > > initialization of the TDX module, vm-scope ioctl is better. > > > > > > > > Since there was agreement to install the TDX module on load, please > > > > place this ioctl on the /dev/kvm file descriptor. > > > > > > > > At least for SEV, there were cases where the system-wide parameters are > > > > needed outside KVM, so it's better to avoid requiring a VM file descriptor. > > > > > > I don't have strong preference on KVM-scope ioctl or VM-scope. > > > > > > Initially, we made it KVM-scope and change it to VM-scope in this > > > version. Yes, it returns the info from TDX module, which doesn't vary > > > per VM. However, what if we want to return different capabilities > > > (software controlled capabilities) per VM? > > > > > > > In this case, you don't return different capabilities, instead, you return the > > same capabilities but control the capabilities on per-VM basis. > > yes, so I'm not arguing it or insisting on per-VM. > > I just speak out my concern since it's user ABI. The reason why I made this API to VM-scope API is to reduce the number of patch given qemu usage. Now Paolo requested it, I'll change it KVM-scope API. -- Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
