> >> >> For the current CCA implementation bind is equivalent to VDEV_CREATE > >> >> which doesn't mark the device LOCKED. Marking the device LOCKED is > >> >> driven by the guest as shown in the steps below. > >> > > >> > Could you elaborate why vdev create & LOCK can't be done at the same > >> > time, when guest requests "lock"? Intel TDX also requires firmware calls > >> > like tdi_create(alloc metadata) & tdi_bind(do LOCK), but I don't see > >> > there is need to break them out in different phases. > >> > > >> > >> Yes, that is possible and might be what I will end up doing. Right now > >> I have kept the interface flexible enough as I am writing these changes. > > > > Good to know that, thanks. > > > >> Device can possibly be presented in locked state to the guest. > > > > This is also what I did before. But finally I dropped (or pending) this > > "early binding" support. There are several reset operations during VM > > setup and booting, especially the ones in bios. They breaks LOCK state > > and I have to make VFIO suppress the reset, or reset & recover, but that > > seems not worth the effort. > > > > May wanna know how you see this problem. > > Currently, my approach involves a split vdev_create and a TDISP lock, which is > why I haven't encountered the issue mentioned above. The current changes > implement vdev_create via the VMM, while the guest makes an RSI call to > switch the device to the locked state. > > I chose to separate vdev_create and TDISP lock into two distinct steps > to simplify the process and better align it with the RMM spec [1]. > > I noticed that SEV-TIO performs a KVM_EXIT_VMGEXIT, which carries out a > similar operation unless it has already been handled during VM startup. > From your reply above, I understand there was a proposal to combine > VDEV_CREATE and TDISP_LOCK. However, you also mentioned that if we > present the device in a locked state to a VM early in the boot process, > we might unintentionally break the TDISP lock state. That doesn't break the proposal to combine VDEV CREATE & LOCK. We end up make VMM do nothing about Secure at VM boot, just normal shared passthrough. VMM does VDEV create & LOCK in a batch when guest asks for bind (or lock or connect, or whatever verb). I think if any device specific thing must be done *between* VDEV CREATE and LOCK, then they must be separated. But I haven't found yet. Thanks, Yilun > > I will look up the previous discussions to better understand the > rationale behind combining vdev_create and lock. > > [1] https://developer.arm.com/-/cdn-downloads/permalink/Architectures/Armv9/DEN0137_1.1-alp12.zip > > -aneesh
