Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF

> > If there is even a slight expectation of confidentiality (IMO just > calling it a 'secret' in documentation is enough to justify that > expectation) it should be treated as such. > > Thus qemu needs to add the possibility to pass it via the 'secret' > object, so that libvirt can pass it encrypted. On the device commandline > we'll just pass the alias to the secret. > > There's a well documented and maintained way to do that so it should be > a very straightforward and quick modification. > > > Until then the problem is that we are unable to launch the VMs when the PF > > is in the uesrspace. For now this patch is only bridging the gap to qemu > > commandline. > > The above should be done prior doing this in libvirt so that we can use > the new approach without having any duplicate code. > Yes, that sounds good. We need to add the mechanism to pass the vf-token via a secret object. However, until it is done we are unable to proceed with our VMs with PF in the userspace unless we provide the vf-token as in this series. So for now either a) the qemu commit needs to be revert (so that we can continue without providing vf-token uuid), OR b) We add libvirt support for clear-text vf-token, then add the choice to qemu to additionally provide the vf-token via a secret object and then update libvirt to pass the encrypted secret.