> > If I understanding correctly then you are recommending that instead of > > exporting various functions from PSP drv we should expose one function > > for the all the guest command handling (something like this). > > > > My understanding is that a user could exhaust the ASIDs for encrypted > > VMs if it was allowed to start an arbitrary number of KVM guests. So > > we would need some kind of control. Is this correct? > > Yes, there is limited number of ASIDs for encrypted VMs. Do we need to > pass the psp_fd into SEV_ISSUE_CMD ioctl or can we handle it from Qemu > itself ? e.g when user asks to transition a guest into SEV-enabled mode > then before calling LAUNCH_START Qemu tries to open /dev/psp device. If > open() returns success then we know user has permission to communicate > with PSP firmware. No, this is a stateful mechanism and it's hard to implement. Passing a /dev/psp file descriptor is the simplest way to "prove" that you have access to the device. Thanks, Paolo > > If so, does /dev/psp provide any functionality that you believe is > > dangerous for the KVM userspace (which runs in a very confined > > environment)? Is this functionality blocked through capability > > checks? > > I do not see /dev/psp providing anything which would be dangerous to KVM > userspace. It should be safe to access /dev/psp into KVM userspace. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>